[Top][All Lists]

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

RE: cvs user, cvs password

From: Andrey Aristarkhov
Subject: RE: cvs user, cvs password
Date: Tue, 13 Aug 2002 18:31:49 +0400

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.

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

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

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

> 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'll add some more comments to the patches.
Looking for it.


reply via email to

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