Andrey Aristarkhov wrote: >See answers bollow. > > >>-----Original Message----- >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf >>Of Derek Robert Price >>Sent: Tuesday, August 13, 2002 4:59 PM >>To: Andrey Aristarkhov >>Cc: [EMAIL PROTECTED] >>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: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com -- 155. I had a life once... now I have a computer and a modem. _______________________________________________ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
