[Top][All Lists]

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

Re: Strategy of access

From: Greg A. Woods
Subject: Re: Strategy of access
Date: Wed, 11 Jul 2001 00:53:10 -0400 (EDT)

[ On Tuesday, July 10, 2001 at 10:16:16 (+0200), address@hidden wrote: ]
> Subject: Re: Strategy of access
> Let see at this example:  user johny has been added to 'project_a' and
> 'project_b' and has full access (he is in 'cvsadmin' group) but there
> is no way to add him to 'project_c' with read-only access.

Well, with basic UNIX permissions if you've set up CVS so that some
projects are read-only to some users then implicitly all users with
access to the CVS repository will have read-only access to all projects.

However real issue is that if you give a user write access to the
CVSROOT module then you cannot literally prevent them from having read
or write access to anything and everything (though total lack of
accountabilty requires a much more sophisticated attack).  Thus
membership in the "cvsadmin" group must only be given to highly trusted
users.  Your policy should not require that members of the "cvsadmin"
group ever be restricted to read-only access of any given module -- they
should be explicitly trusted with write access to all of $CVSROOT.

With very very very careful use of per-file (er, per-directory) ACLs you
can provide much finer grain control over read-only access, but of
course you'll have to implement the server on a system which supports
such ACLs, and of course you'll really have to totally avoid cvspserver
(though you must avoid cvspserver anyway if you're this concerned about
implementing solid technical access controls!).

> If johny is
> removed from cvsadmin group he will unfortunatelly lose 'write' access
> to all projects not only 'project_c'.

No, that's not true at all.  I don't understand the problem you seem to
see here.

If you've set up the CVSROOT module access properly then users do not
need to be members of the "cvsadmin" group just to have write access to
one or more projects.  The CVSROOT module is just a separate project
from that point of view.

Yes there is the "CVSROOT/history" file, and optionally some files that
might be written by programs called from specs in CVSROOT/*info files.
However you don't need write access to the $CVSROOT/CVSROOT directory
just to be able to write to some file within that directory.  Depending
on your specific circumstances you can either make the history file
world-writable or create some "cvsusers" group which all CVS users must
be a member of (and which would group-own the group-writable history

                                                        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]