[Top][All Lists]

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

Re: cvs user, cvs password

From: Derek Robert Price
Subject: Re: cvs user, cvs password
Date: Tue, 13 Aug 2002 15:58:23 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606

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
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

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



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.

reply via email to

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