[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: File permissions [make that directory permissions!]

From: Tracy Brown
Subject: RE: File permissions [make that directory permissions!]
Date: Tue, 22 May 2001 14:19:42 -0700

> > (They already have
> > ssh access, at this moment, at a later time I might 
> consider pserver if
> > I want to add people to the project that shouldn't have a shell
> > account...)
> No, don't do that.  There's no protection in CVS to prevent users from
> doing almost arbitrary things (nor should there be -- CVS is not a
> security tool!).  Furthermore there's no accountability in 
> pserver.  Use
> real Unix accounts for what they're designed for!  If you don't trust
> someone with a Unix account then you certainly can't trust them with
> your code.  If the issue is really that they can't be trusted 
> with some
> other thing on the same server then your only real option is 
> to move the
> CVS repo to some other machine where there's no conflict between trust
> requirements.

I'm a little confused. For my user base, none have UNIX shell accounts. 
In the pserver password file:

The $USER var will return the user (bob) and not the optional user_to_run_as

(pubcvs) as noted in the above example. Thus, I can hold my users
accountable to their modifications made in the repository. This is done
by having one of more accounts such as pubcvs in the example above. Bob
will authenticate with his password and run on the pubcvs account and yet
all Bob's transactions will be his and not pubcvs's.

As an administrator I really don't want to manage 100+ UNIX accounts just
because I should trust them... that's a hassle. And we don't need to - 
we can obtain accountability without this silly hassle.

And if you want to impose permissions, use a set of UNIX groups with a set
of public cvs accounts (i.e. pubcvs1, pubcvs2, pubcvs3, etc.). Oh, and keep
the password for these users to yourself, turn off telnet, turn off ftp, and
all that UNIX administration stuff.

If security is on your mind:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]