Re: cvs user, cvs password

[Derek Robert Price]

Andrey Aristarkhov wrote:

> See answers bollow.
>  
>
> > -----Original Message-----
> > From: bug-cvs-admin@gnu.org [mailto:bug-cvs-admin@gnu.org] On Behalf 
> > Of Derek Robert Price
> > Sent: Tuesday, August 13, 2002 4:59 PM
> > To: Andrey Aristarkhov
> > Cc: bug-cvs@gnu.org
> > Subject: Re: cvs user, cvs password
> >    
> >
> > > These commands have simplest security restrictions and 
> > > considerations: 0. There must be a user named "admin" in CVS 
> > > repository who has full rights to modify users in the CVS repository.
> > >
> > >      
> > Why add a new user?  Why not use the UNIX `cvsadmin' group like the 
> > `cvs admin' command does: 
> > <http://www.cvshome.org/docs/manual/cvs_16.html#SEC119>?
> >    
> Here is a quotation from SEC119: "... On NT, the cvsadmin feature does
> not exist and all users can run cvs admin...". This is a reason I've
> added administrator account to CVSROOT/passwd. I've also mention that
> it's always easier to keep all users in a single place. Moreover,
> command "user" does not allow users change their aliases: administrator
> password is needed to known. If we will configure access to
> administrator privileges for command "user" using OS capabilities, there
> would be a great work to do it consistent for different OSs.
>  

Is this really a lot of work?  First of all, do you really have an NT 
server set up using stock CVS?  Can I see _those_ patches if you do? 
It's the server that needs to be able to look up groups.  Even so, and 
I'll grant that Windows isn't my strongest area, is it really so hard to 
look up the group memberships of the current user and compare each item 
in the list it to a string?

Or are you running CVS with a local repository?  I didn't look - ah - 
you are.  Your code won't run over :pserver: or you would have had to 
change at least `server.c'.

I don't think I'd add this change without it working with remote 
repositories.  First of all, the security is trivially easy to break - 
if the CVS executable can change the files, so can the user, either by 
hand or by downloading an older version of CVS and using that.  Second, 
everything that CVS can do should work in both modes, as 
indistinguishably as possible.

> > Even better would be a permissions API that accepts some token 
> > representing the action (say a string "name"), and a list of data, 
> > then returns true or false and maybe an error message, but that's 
> > probably too much to hope for at the moment.  :)
> >    
> I've just implemented such API for CVS. Idea is simple. There is a file
> CVSROOT/accessinfo with the following format:
> MASK    /program/to/execute     all | <cvs command list>
> where MASK is a standard mask, recognized by Parse_Info.
> The last argument(s) in a line is a list of cvs commands to be
> "filtered". For example
> CVSROOT /etc/cvs/sbin/check_access.sh           commit checkout export
> add
> In this case check_access.sh will be run if one of the commands will be
> executed by CVS. check_access.sh takes 3 parameters: 1 - cvs command, 2
> - repository or string 'null', 3 - cvs username or caller principal.
>
> If filter exits with status > 0, error reported.
>  

I might be sorry I brought that up.  There are at least two other ACL 
systems for CVS.  One is Corey Minyard's, which seems to be fairly 
popular, and the other is a pet project of mine - porting some CollabNet 
code back into the main source: 
<http://ccvs.cvshome.org/issues/show_bug.cgi?id=25>.  There should be 
links to Corey's patch on cvshome.org.  If they aren't recent you might 
try the CVSNT and/or cvs-nserver projects.

I like the XMLRPC version for making the authentication and ACL system a 
plugin.  On the other hand, Corey's put a lot more thought into an API 
that works well with CVS.  The best solution is probably implementing 
Corey's ACLs over the XMLRPC interface and then letting the external 
plugin make its decisions and store its data however it likes.

> > `cvs passwd' would be available to all users, so it makes sense that 
> > it be given a full command namespace, but does it make sense to make 
> > `cvs user' its own command rather than part of the the `cvs admin' 
> > command?
> >    
> I agree that 'cvs user' can be a part of 'cvs admin' command. I'd say
> it's more logical.
>  

I think so too, the more so the more I think about it.  It seems to be a 
good principle to avoid polluting the common user's namespace with 
commands they won't use.  The simpler the better.

> > You could use the existing `cvsadmin' group restriction for free 
> > then, I think.
> >    
> Derek, you've forgot about NT. I'd say, cvs should rely on it's own user
> list. I believe, it will be less complex for configuring cvs under
> different OS.
>  

sic.  I still think this shouldn't be too hard, but the remote server 
issues still apply.

> > Of course, if added, `user' should be restricted regardless of the 
> > existance of the `cvsadmin' group, so maybe the extra work would be 
> > necessary anyhow.
> >    
> I think "user" must always use internal CVS account for access
> restrictions.
>  

I think you're right, but I'd still like to see it use the same 
`cvsadmin' group or not work at all.

Derek

--
               *8^)

Email: derek@ximbiot.com

Get CVS support at http://ximbiot.com
--
155. I had a life once... now I have a computer and a modem.