info-cvs
[Top][All Lists]
Advanced

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

New, Improved cvs_acls contrib for Access Control


From: Peter Connolly
Subject: New, Improved cvs_acls contrib for Access Control
Date: Thu, 26 Feb 2004 11:16:35 -0800

The original 'cvs_acls' script in 'contrib' wasn't doing what I 
needed and the directory permissions approach:

http://www.cvshome.org/docs/manual/cvs-1.11.13/cvs_2.html#SEC13 

involves too much administration as well as not handling individual 
file restrictions.  

I rewrote the 'cvs_acls' script to do what I needed and called it 
'cvs_acls2'. Please see attached. 

I'd like to submit it to 'contrib' but do not know what the proper 
procedure is.  Could someone explain the process?

--------------------------------------------------------------------

Here's a list of the problems I encountered when I tried to use the
original ('cvs_acls' from v1.11.13):

 0) Multiple entries on an 'avail' line will be matched 
    individually, instead of requiring that all @ARGV entries match 
    all 'avail' entries.
      (IMO, this basically made the original script unuseable for us 
      since any arbitrary combination of committed files could avoid 
      matching the 'avail's entries.)
 1) Correctly handle specific filename restrictions
 2) Correctly handle multiple, specific filename restrictions
 3) Prohibit mix of dirs and files on a single 'avail' line
 4) Correctly handle a mixture of branch restrictions within one 
    work directory
 5) Do some sanity checking on the 'avail' file
 6) Accurately report restricted entries and their matching patterns
 7) $CVSROOT existence is checked too late
 8) Expanded overly complex PERL REGEXPs for readability and 
    maintainability
 9) Correctly handle the CVSROOT=:local:/... option 
    (useful for testing)
10) Skip the rest of processing if a mismatch on portion of the 
    'avail' line
11) Get rid of opaque "karma" messages in favor of user-friendly 
    messages that explain what the permission restrictions were
12) Add optional 'restrict_msg' file for additional restriction 
    messages.
13) Take a "-u" parameter for $USER from commit_prep so that the 
    script can do restrictions based on the client-side userId 
    rather than the server-side userId (usually 'cvs').
14) Added a lot more debug trace 
15) Tested these restrictions with concurrent use of pserver and SSH
    access to model our transition from pserver to ext access.
16) Added logging of restricted commit attempts.
    Restricted commits can be sent to a default file:
    $CVSROOT/CVSROOT/restrict_log or to one passed to the script
    via the -f command parameter.
17) Added commit-error message include for site-specific contact
    information. Default file is: $CVSROOT/CVSROOT/restrict_msg

Things still left to do: 

 1) Need to deal with pserver/SSH migration that may have conflicting 
    umasks?
 2) Refactor checkDirectoryMatch and checkFileMatch together.
    (Can pass in match expression?)
 3) Use some CPAN module to handle command parameters.
 4) use some CPAN module to clone data structures.

==== Version information

I'm not offering this as a fix to the original 'cvs_acls' script since 
it differs substantially in goals and methods from its original and 
there are probably a significant number of people out there that still 
require the original version's functionality.

Please note that there has been very limited cross-platform testing of 
this script!!! (We did not have the time or resources to do exhaustive
cross-platform testing.)

It was developed and tested under Red Hat Linux 9.0 using PERL 5.8.0.
Additionally, it was tested under Red Hat Linux 7.3 using PERL 5.6.1.
It is now running on our main development repositories under Red Hat
Linux 7.3 using PERL 5.6.1.

pc

Peter Connolly, CNET Networks, Inc.
address@hidden

Attachment: cvs_acls2
Description: Binary data


reply via email to

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