[Top][All Lists]

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

Re: File permissions [make that directory permissions!]

From: Greg A. Woods
Subject: Re: File permissions [make that directory permissions!]
Date: Tue, 22 May 2001 14:06:12 -0400 (EDT)

[ On Tuesday, May 22, 2001 at 15:57:34 (+0200), Hugo van der Merwe wrote: ]
> Subject: File permissions (Was: Re: pserver vs. ssh - performance ...)
> Having now started using my CVS repository for shared projects instead
> of just personal ones, I have come to wonder about file permissions...
> my cvs repository belongs to the "src" group, so I add users to that
> group if they should have access to the repository.

sounds good so far!

(well, except for the part about "file permissions" -- CVS uses
directory permissions to control access to all the files within that

((yes, pedantically a directory is a file.... :-))

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

> Now I wonder, as any of those users can modify any file in this
> structure, is "trust" the only way I can stop them from messing with my
> other projects?

If you want to provide separate "rights" to modify different modules for
different groups of users then the simplest scheme is to create a unix
group for each common group of users and then make all the directories
in each module for a group of users be owned and writable only by their
unix group.  You have to take care to maintain this properly, especially
if your filesystem doesn't help do it with you (i.e. new directories
must be checked and perhaps corrected).

> (Must I create a second repository with different "group
> ownership" for this?)

Not necessarily, but you can also do this too.

> Secondly, with any user being able to modify
> CVSROOT, as what user does the commands get executed, e.g. commit mails
> from commitinfo... these run as the user doing the commit I assume? That
> means any user can cause any other user to run an arbitrary command as
> himself... ?

The CVSROOT directory is just another module.  Create a "cvsadmin" group
and make the $CVSROOT/CVSROOT directory writable only by that group.
Only add users to the "cvsadmin" group if you want to allow them to
administer the CVS repository itself.

Indeed anyone with write access to the CVSROOT module can introduce
"trojan horse" programs into the *info files (or the scripts or programs
already configured in the *info files if you also install those scripts
and programs in the CVSROOT module instead of in some secure place where
they really should be).

                                                        Greg A. Woods

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

reply via email to

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