[Top][All Lists]

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

Re: acl for cvs try II

From: Edward Peschko
Subject: Re: acl for cvs try II
Date: Mon, 30 Jun 2003 13:09:07 -0700
User-agent: Mutt/1.3.22i

> >#1 is key for me - I need something where I don't need to download a new 
> >client for 
> >everyone who wants to use ACL. #2 is pretty important too - I want something 
> >centralized,
> >one file that I can check and see at a glance who has access to what. If #1 
> >and #2 holds
> >for your patch, then like I said I'd be more than happy to use it.
> >
> For single file centralized access that the users don't have control
> over, I believe you could easily set up a shell script to handle that. 
> No need to modify CVS.  I've never done it, but if that's what you want,
> I'd recommend trying the shell-script approach.  It will be easier to
> maintain in the long-term.

Ok, how? From what I saw in the source code, there was nothing preventing files 
propogating to the users; and there was also nothing preventing users from 
seeing what 
directories/files existed on the server (ie: there was no filter that prevented 
traffic back to the client, even if the client would not get the files.)

I looked at shiela, but again, it looked too complicated for my use - 
programming a 
bunch of hooks into different info files per operation.  Plus it required a not 
insignificant overhead of installing perl, and a non-trivial setup.

As for maintainability, simple ACL is really not that bad - all I did was put a 
into 'do_recursion' - which pretty much every command touches - and voila! 
instant ACL.
If you don't have a aclinfo file, the command is a no-op - hence it defaults 
back to 
vanilla CVS.  

My intent was to make 'aclinfo' ubiquitous, like all the 'info' files, like 
on unix. You want acl, you put your information in aclinfo and you are 
guaranteed that 
not only will users not get the files, they won't even see that they are there.

And I maintain that its more unmaintainable to have several, incompatible shell 
implementing acl in subtly different ways than it is to have one, centralized 


reply via email to

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