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

[Greg A. Woods]

[ 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
>
> We have CVS pserver runing as a non-root user. The pserver cvs binary has
> update and checkin .prog disabled in server.c (client binary has to have it
> enabled to work properly). I had the UNIX admin add one line to services file
> and one line to inetd.conf and then the SA washes his hands of the CVS stuff. 
> I
> maintain the CVS passwd file and reader/writer files.

Ah, yes, cvspserver without initial execution as root is a somewhat
different critter.

However it's differences really only make it suitable for use in
creating anonymous read-only servers, and even if the chosen user-id has
no permissions whatsoever in the repository I'd still be paranoid enough
that I'd only ever set up such a configuration on a separate machine
hosting only a copy of the repository I'm offering anonymous access to.

> 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?)

>     - 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!

>     - 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!  :-)

>     - does not require mucking with UNIX groups for access control (ie. if
> user1 with write access to repo1 repo2 and if user2 with write access to repo2
> repo4)

You really Really REALLY do want to use Unix groups for access control
between modules, if you want such access control that is!  That's how
unix filesystems work!  You MUST use Unix IDs!  The Unix security model
requires you to use real Unix IDs (and groups if you need them).

>     - allows all users read access to all repositories

That's trivial with the right permissions settings and use of LockDir in
the CVSROOT/config file.

>     - dealing with checkin and update .prog (if necessary)

I've no idea what that means....

> Greg, you are very persistant about security and using SSH (or similar) with
> CVS (particuarly pserver). Seeing the number and frequency of your postings
> (particular posts from others that open the door to your anti-pserver 
> crusade),
> 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'm telling you that you must use Unix IDs because you simply must.
That's the way the entire system security model works.  If you don't use
it correctly then you're circumventing the entire model (not just the
inherent security).  If you don't use Unix IDs then you might as well
host your repository on a single-user system -- you'd be better off
because you wouldn't have a false sense of security!

> 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!

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.

        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)

        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!

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>