[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: cvs user, cvs password
RE: cvs user, cvs password
Tue, 13 Aug 2002 18:31:49 +0400
See answers bollow.
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] On Behalf
> Of Derek Robert Price
> Sent: Tuesday, August 13, 2002 4:59 PM
> To: Andrey Aristarkhov
> Cc: firstname.lastname@example.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:
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'
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
> 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.