[Top][All Lists]

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

RE: ACL status

From: Rafael Sanz
Subject: RE: ACL status
Date: Fri, 14 Jan 2005 16:40:00 +0100

Many thank Todd.

Excuse me, is OS (Operating System like you are deduced :-)

About the requirement of change owners and groups it's a restriction of our
enterprise security policy and it's out my scope change it (in Linux root
privileges are needed and in Solaris was needed some special settings to
grant a user permission to change his own files).

Until now, I was working with little groups but the success of CVS has grown
the number of projects and kind of files. My problem came when need
incorporate business docs and handle complex rules of access.

The raw security access I have guaranteed for SSH access, but any constraint
to a user browse the repository and checkout a file into the same

I'm looking for something handled in a centralized method (admin file, LDAP,
etc.), not accessing to the repository files (like this, but the most standard possible).

Thanks in advanced.

-----Mensaje original-----
De: address@hidden [mailto:address@hidden En
nombre de Todd Denniston
Enviado el: viernes, 14 de enero de 2005 14:27
Para: Rafael Sanz
CC: address@hidden
Asunto: Re: ACL status

Rafael Sanz wrote:
> Thanks Peter and Arthur.
> About the contrib scripts are not enough because only restrict commits
> (currently, I'm resolved this with a perl script hook at commitinfo and
> taginfo events).

Gross permissions with cvs (not sure about CVSNT under windows) are done at
the filesystem level, i.e., either you can read from the project repo or not
depending on the filesystem permissions.
Writing to the repo is controlled also by the filesystem permissions, but
can have further fine grained control using cvs_acls scripts.

If you are using pserver the reader/writer set performs much the same gross
permissions as the filesystem permissions, but should be backed up by the
filesystem permissions, because the filesystem permissions are more sure to
work if the person is logging in with an operating system loggin instead of
a pserver password.  If you are really concerned about security and
segregating your users, be aware pserver has not had a great track record
(in the last couple of years at least), check the archives of this list for
more info

> The only way that I found is using the SO groups and users, is similar in
> CVSNT if I understand well. But I don't understand how work chacl exactly:
Please clarify what you mean by SO groups... I do not immediately recognize
the acronym.
Do you mean Italian for Operating System?
(Assuming you do for this email)

> -change the SO permission of repository file?
Not files, directories. cvs_acls may allow per file.

> -Are stored the permission in somewhere? (I understand is in the SO
> repository file attribute, then how is controlled the branch?)

for cvs_acls[2] it is in cvsacl file, read the "Admin Setup" section of

> -And my Achilles heel, chacl close the read permission for specific
> files/directories?
> I'm reading this manual but I don't
> understand completely the differences in ACL control between CVS and CVSNT
> (except native commands to do it in CVSNT)
> Currently I manage a CVS server on Solaris and the security rules of SO
> administrators are in conflict to grant access over modify users/groups,
> I must change to cvsnt is a valid option but I need understand the gains
> this, because the mechanism in CVSNT (if I understand well) have the same
> problem.
What conflict do they really have? 
Do they not want to maintain the file, or is it that they do not want to let
you maintain it? If it is they don't want to maintain it, some one should
remind them it is their job to support the users (either they make changes
or allow you to), if it is that they don't want to let you change the file
(directly) I can understand their perspective as an admin myself, but they
must chose one of the two update methods and go forward.
For my building, the task (or project) lead identifies the people working
for him/her and notifies the admin group who they want in the unix group
file for their project, the admin makes the change and then the task lead
uses the unix group for their repository.  For my building this has always
been enough, i.e., we have not had to use cvs_acls and the like.

> Some other link that clarify me?
If someone's user id & group id does not have read access to the repo
directories, then they can't read the data from cvs. see:
Look for  LockDir in the next one 

> Thanks in advanced, again.
> -----Mensaje original-----
> De: Arthur Barrett [mailto:address@hidden
<pointed out some ACL stuff is already integrated in CVSNT>
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Rafael Sanz
> Sent: Friday, 14 January 2005 2:31 AM
> To: address@hidden
> Subject: ACL status
> Hello, I need to extend my cvs server with fine grain of Access Control
> Level (beyond writers or readers files natives in CVS standar).
> I'm found some references to patches at C code
> (, but any is standard...
> What is the develop status of ACL in cvs server for UNIX?? Is in
> progress?
> Nothing about?
> Whatever, some link better to ACL solutions that deal with read
> restriction
> for files or directories?
> Thanks in advanced.

Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter

reply via email to

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