RE: cvs user, cvs password

[Andrey Aristarkhov]

> -----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 11:58 PM
> To: Andrey Aristarkhov
> Cc: bug-cvs@gnu.org
> Subject: Re: cvs user, cvs password
> 

> >>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'.
Yes, I use local repository for development.
I did not make any changes to server.c, but 'cvs user|password' works in
pserver mode: I've made corresponded tests. Telling the true, I don't
understand _why_ it works, but it _do_ works. Even if server.c will need
patches, they are trivial.

> 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.
I've already mentioned, that pserver mode is supported. It's absolutely
transparent for user which mode is used - local or pserver.
You are right about security triviality. But this is that case where OS'
permissions can help. 

> >>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.
> >
> >
[skipped]
> 
> 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.
My idea of 'accessinfo' file is similar you've described one above. You
place filter script (plugin) into accessinfo and lookup result of its
execution. Actually the script could use any mechanisms to make a
decision to grant or deny access (for example, by means of contacting
CORBA-server or Directory-server). I believe that implementation of this
plugin mechanism is much easier and compact than XMLRPC or any other
ones.

> >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.
Can we make sub-namespace 'user' of 'cvs admin'? In this case I can
quickly incorporate user.c's logic into admin.c. In this case cvs
command will look like 'cvs admin user ...'. I can suppose, that it will
be more convenient other than using different options.

> >> 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.
No comments yet.

> >>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.
If user will be in admin command namespace, I think it should use
'admin's access restrictions.

Regards,
Andrey