Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Thomas Keller wrote:
> Hi Bo!
>
>
>>>>a) Do I need to have an "writers" file at all when I use chacl?
>>
>>ACL:s will handle all of the permission stuff for you, but you have to
>>*limit* general unspecified access first. By default all users have
>>full access so specifying read access for a specific user somewhere
>>will only add read to already existing read/write, which obviously is
>>not getting you where you want to be.
>
>
> So this means effectively I need to remove my readers and writers file
> before I can start using ACLs? Are ACLs independent from underlying
> system permissions (e.g. Linux file system permissions)?
>
No. Think of it as levels of permissions.
Those in the readers file can at most ever read regardless of what an
ACL says.
They can be prevented from reading parts of the repository by using a
"noread" acl.
Those in the writers file can in the first instance write to any part of
the repository. Using acls you can designate where they are not allowed
to write to using the nowrite,notag,nocreate acl directives.
To make sure that a user can't change the acl where they should be able
to you also need to specify the nocontrol acl.
>>>>b) I've tried to gave user "joe" write access to a single directory and
>>>>read-only access to the rest by doing # complete module
>>>>$ cvs -a read -u joe -m "You have only read access to this file/folder" .
>>>># certain directory
>>>>$ cvs -a read,write,control,tag -u joe foo/bar
>>>>Both commands succeeded, but if I test my restrictions the user has still
Its all about explicitly denying users the right to do things as well as
allowing them to do things.
Just say you have a sandbox with a checkout of "ourproduct" that
contains two directories.
C:/sandbox/ourproduct/joes_writable_part
C:/sandbox/ourproduct/joes_readonly_part
And just say that your username is "thomas" and you have write
permission to the entire repository. You need your username in the
CVSROOT/admin file in the actual repository. (Note you need to create
the CVSROOT/admin file directly in the repository. It is not revision
controlled and can't be checked out to a sandbox.)
Now, You want joe to be able to write to at least some part of the
repository so you need to put his user name in the writers file. Put
yours in for good measure.
ie
cd c:/sandbox
cvs -d :sspi:thomas at server:/Repos co CVSROOT
cd CVSROOT
echo "thomas" >>writers
echo "joe">>writers
cvs commit writers
#Now to set the acls
cd C:/sandbox/ourproduct
#for good measure make yourself the owner of the directory
cvs chown thomas .
#give yourself full permissions
cvs chacl -u thomas -a read,write,tag,create,control
#give everyone else read permission only and deny everything else.
cvs chacl -a read,nowrite,notag,nocreate,nocontrol
#Now give joe full capabilies for his part of the repository
cd C:/sandbox/ourproduct/joes_writable_part
cvs chacl -u joe -a read,write,tag,create,control
Everyone else not mentioned will inherit the acls from the directories
above.
Note: Upcoming functionality (Not sure which version it appeared or if
it is released as recommended yet) will give an adminstrator the ability
to deny access by setting the default configuration option called
AclMode in the CVSROOT/config file.
<snip http://www.cvsnt.org/manual2/html/config.html>
AclMode=value
Select the access control list mode. One of 3 values:
*none - No extra access control is done on this repository.
*compat (default) - Default access mode is to allow access.
*normal - Default access mode is to deny access.
</snip>
Setting this to "normal" will mean that the way you expected ACLS to
work will be correct. Ie you won't have to explicitly deny the things
you don't want a user to be able to do. Ie you won't have to take away
rights you will have to award rights to particular users.
I haven't tried it yet because I am still using 2.0.58d, now pushing a
theoretical 220 users ( They don't all use it yet but maybe one day).
When they do the deficiencies of 2.0.58d with regards to group related
ACLs will become more prominent. This AclMode along with fixes to the
ACL functionality is probably yet another reason for me to upgrade.... soon.
Cheers
Mikew.