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