RE: New update to the CVS ACL patch to support user groups

[Mark]

--- "Greg A. Woods" <address@hidden> wrote:
> [ On Wednesday, July 25, 2001 at 06:49:14 (-0700), Mark wrote: ]
> > Subject: RE: New update to the CVS ACL patch to support user groups

> > Without root access (or as limited root assistance as possible), can you
> > explain the set up CVS client/server using SSH that has/addresses the
> > following:
> >     - prevents all users from any type of write acces to the CVS repostory
> file
> > structure (they may or may not have there sand boxes on the server machine)
> 
> Do you mean to set up anonyous read-only access?  Or do you mean to
> prevent users from gaining shell-level access to the repository
> directories?  (If the latter then you don't have that now, so what are
> you asking for it for?)

Just preventing write access, (cp, mv, chmod, etc...) (ls, cd, cat, etc.. are
okay)

> >     - does not require users to have accounts on the server machine
> 
> You really Really REALLY do want all authorised CVS users to have real
> system accounts on the machine.  To do otherwise bypasses the Unix
> security model entirely.  SSH requires real Unix accounts because Unix
> requires real Unix accounts!  You really Really REALLY do want them,
> whether you know it or not!  You need them.  You MUST have them!

I don't know about issuing UNIX accounts to Windows developers for the sole
purpose of accessing the CVS server. I work in a large company. Support from
the (understaffed) Unix Admins is not really available (they have there hands
full with clearcase and supporting production environments, and adding to their
taskload (if they are willing to accept it)is not a way to win their support on
real issues) and they don't want to be bothered with aditional tools to
support. The SA's don't want CVS running as root so they don't have to support
it and don't care that CVS pserver runs as the same non-root user for everyone.
To have the SA's create and maintain unix accounts (groups memberships)
countinually for all users is a drain on everyone. Also, if SSH requires root
to install and maintain, thats and additional burdon (unless I can do this
without root) on the SA's. All things considered, pserver is a very nice and
attractive way to handle things. If I could take on SSH admin myself (without
root) and could handle repostory write access like pserver readers/writers
(without having to deal with unix groups), then I would be willing to consider
the startup costs of setting up real accounts for windows developers on the
UNIX side.

> >     - provides repository level write access controls (simlar to
> > readers/writers)
> 
> Well, obviously once you have real Unix accounts you can use real unix
> filesystem access controls!  :-)

Thats another issue. I don't have root. I can't get root. If we want to have a
CVS environment, we have to do it without root. Also, pserver allows us to do
this without messing with group memberships with the readers/writers files. 

> > I was wondering if you would have the time to help those less experienced
> or
> > knowledgeable than yourself, educate and provide alternatives, rather than
> > continually post that CVS is not secure and to use SSH (or similar).
> 
> Well, if you'd stop wishing for the impossible and simply do things in
> the way they were designed to be done then you'd have no problem at all.

I currently do not have any problems. We are on a private network behind a
firewall. If pserver was riped out of CVS, what functionality/features would go
with it? Since .rhost files are commonly banded at companies from what I have
seen, what is left if pserver is removed from CVS C/S protocol?

> > Maybe a simple "How to setup a SSH equivalent for pserver" text document is
> all
> > that is needed to help people migrate from pserver to SSH.
> 
> I think what's in the respective SSH and CVS manuals should already be
> sufficient.  It's really not that hard to do, and it's MUCH simpler than
> anything to do with cvspserver.  Everything's designed to work that
> way together and these things just do work together almost automatically!

I am begining to think that my setup with non-root pserver is the simplest for
my environment.

> If you can tell me what stumbling blocks you're encountering, (and don't
> try to tell me you need the impossible -- you can't have it), then I'm
> more than willing to assist you or anyone else in reaching a correct and
> functioning configuration.  Note though that I don't do M$-Winblows.
> You cannot really use SSH securely on any single-user client OS.  You
> can still use it if you want, and it works fine, but I won't explicitly
> help anyone do it unless they first pay me my full rate up-front so that
> I can start out by telling them face-to-face that they've no real
> security anyway, and then if they accept that state of affiars we can go
> about creating them a false sense of security.
> 
> The basic steps to success are:
> 
>       1. create Unix accounts for all authorised users (worry about
>          separating them into different groups later), assign them
>          passwords, etc.

Thats just it. I don't want to mess with Unix accounts and especially
maintenance of group lists. I don't have root access. At my current job this is
not a reasonable implementation of CVS. Is there any other c/s CVS setup
besides pserver doesn't depend on root to maintain accounts or group lists?
This is a feature that pserver provides.

maybe at a different job where I may have root on the server or the SA's are
more responsive, and the number of projects and developers are smaller and
don't move around as much, I can forgo pserver setup. but pserver should not be
riped out of CVS. It has its uses. there are ups and down to everything. 

>       2. install and configure SSH where necessary and make sure they
>          can all "ssh server.host id" and get back the output of the
>          Unix "id" command (i.e. you probably want to use SSH in the
>          mode where users don't have to enter a password every time,
>          which means the client and server hosts must trust each other
>          implicitly, and the server must trust the client to have
>          authenticated the user properly and securely)

I will definetly play with this SSH setup at home to see if I can get it
working.

>       3. Add "CVS_RSH=/path/to/ssh; export CVS_RSH" to /etc/profile
>          (or ~/.profile, or similarly to /etc/cshrc, etc.) on all the
>          client machines.  Also add a similar setting for $CVSROOT,
>          using the ":ext:" syntax discussed in the manual, to point
>          them all at the CVS server.
> 
> That's it.  That's all there is to do.  From there your users can
> checkout and work just as they did with cvspserver, but they'll be doing
> it securely.  Just "cvs co blah" and away you go!

Thanks, this is good to know and I will try it out. But I still think
(non-root) pserver has its place and uses, IMHO, pserver is better than sgid
bits on cvs binaries or trying to keep up with set bits on directories and ACL
access controls, or patching CVS to do these things.

Once I get SSH and CVS setup at home, I will be more prone to use it at work if
the situation is right.

Mark

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/