[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Directory based Access Control
From: |
Infoman: Martin Kretschmar |
Subject: |
Directory based Access Control |
Date: |
Thu, 3 May 2001 15:13:44 +0200 |
Hi,
I would like to make use of the standard linux access control
for directories, but somehow it doesn't seem to work quite
right for me.
From "Access Control in CVS":
Setting the operating system's file permissions of files
in the repository is pretty much an all-or-nothing thing.
Users will need write access to the repository to write
to the repository, but also to read it (because CVS needs
to create lock files). However, on an all-or-nothing level,
this can be useful (see for example the CVSUMASK feature).
For test purposes I have two different users, "user_rw" and
"user_ro". Both belong to the "developers" group, but for a
specific subdirectory the owner is set to "localcvsadmin",
the owning group is "specialists". "user_rw" belongs to
"specialists" but "user_ro" not. The file ownerships for all
files in the subdirectory are "localcvsadmin.specialists",
the permissions identical "rw-rw----".
If "o+w" is set for this directory, using WinCVS 1.2 with ssh
for "user_rw" and "user_ro" allows both to checkout as they
should but also both to commit changes. The permissions work
as they should for local logins.
If "o-w" is set for this directory, this will result in read-
lock errors for checkout and both users:
cvs server: failed to obtain dir lock in repository
`/data/cvshome/GreatProduct/LibSub'
cvs [server aborted]: read lock failed - giving up
Specifying a LockDir in CVSROOT/config works well for both
users and checkouts.
But trying to commit changes will result for both users:
cvs commit -m "no message" Test.htm
Checking in Test.htm;
/data/cvshome/GreatProduct/LibSub/Test.htm,v
<-- Test.htm
new revision: 1.7; previous revision: 1.6
cvs [server aborted]: could not open lock file
`/data/cvshome/GreatProduct/LibSub/,Test.htm,':
Permission denied
Experiments with the "sticky" bits set were not successful
either up to now.
Any ideas how this might be accomplished are welcome.
Regards,
Martin Kretschmar
- Directory based Access Control,
Infoman: Martin Kretschmar <=