info-cvs
[Top][All Lists]
Advanced

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

Re: CVS access control


From: yap_noel
Subject: Re: CVS access control
Date: Wed, 26 Sep 2001 10:37:30 -0400

Personally, I'm against the idea that CVS implement its own directory-level
ACLs  -- this is a file system issue.

If one were to be developed, though, the interface (eg set and get ACLs)
should default to using file system ACLs if available.  If file system ACLs
aren't available, I would prefer this information be kept within the CVS
subdirectory of the repository (as a side issue, I think the location of
the CVS subdirectory should be configurable just like LockDir).  Also, the
ACLs should stick to standard permission semantics.

Noel

To meet the needs of a large repository with numerous users, I've been
playing
with adding directory level access control to CVS.  (The repository is
hosted on
a server which does not have native ACL support in the file system and I
don't
want to give the casual administrator shell access to the server anyhow).

It works as follows;

A client starts CVS on the server and just after the server checks to see
if the
command being issued is allowed by checking CVSROOT/readers and
CVSROOT/writers, it then looks for the file CVSROOT/access/%username%.  The
access file contains a simple rule chain for determining access to
directories.
In the guts of CVS (recurse.c) where it does all the heavy lifting, it
checks
each directory that is entered to see if the user has the necessary access.
If
the user does not have access then it's as if the directory doesn't exist.

The access files have the following format:
<"READ"|"WRITE"> <DIRECTORY REGEXP>

A typical file could look like this:
READ ^Readable
WRITE ^Writable
READ ^Read/Access/But/Not/Below/Here$
WRITE ^Write/Access/But/Not/Below/Here$

When the file is loaded it is parsed in READ or WRITE context based on the
command being issued (much like the tests against CVSROOT/readers and
CVSROOT/writers).  If the command requires READ access then the rules which
grant READ or WRITE access are considered.  If the command requires WRITE
access
then the rules which grant READ access are ignored.  If the access file
exists
for a user then all directories in the repository which don't match any of
the
rules are considered as NO ACCESS.

Anyhow, the reason I'm posting is to get your feedback on such a scheme.

Matt.



_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs




This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.




reply via email to

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