info-cvs
[Top][All Lists]
Advanced

[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




reply via email to

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