Re: CVSROOT/passwd enhancements
"LJ" == Larry Jones [EMAIL PROTECTED] writes: LJ I'm considering making some enhancements to the CVSROOT/passwd file LJ format and I'd like people's opinions: LJ First, I'd like to interpret "*" in the password field as "the system LJ password for this user". That would allow people who are not concerned LJ Second, I'd like to interpret "*" in the username field as "any system LJ user". That would allow even more simplification -- for example: a) this surely allows for rather twisted configrations like "authenticate cvs user against system database and switch to yet another system user, not the user that was authenticated against". To me this is not as clean as using system accounts as CVS accounts for filesystem level access control or using CVS accounts with single system account for CVS-level fine-grained access control. This is where cvs-nserver steps in, allowing everything beforementioned and also PAM if you need this and have this. http://alexm.here.ru/cvs-nserver/ --alexm, cvs-nserver PR droid
Re: CVSROOT/passwd enhancements
Yummy! :-) Please go ahead as described! /Palle [EMAIL PROTECTED] (Larry Jones) writes: I'm considering making some enhancements to the CVSROOT/passwd file format and I'd like people's opinions:
Re: CVSROOT/passwd enhancements
"Larry" == Larry Jones [EMAIL PROTECTED] writes: I'm considering making some enhancements to the CVSROOT/passwd file format and I'd like people's opinions: First, I'd like to interpret "*" in the password field as "the system password for this user". That would allow people who are not concerned with network security to use system passwords along with user mapping. For example, one could have a CVSROOT/passwd that looked like: john:*:cvsadmin lisa:*:cvsadmin bill:*:cvsuser anne:*:cvsuser Been there done that. This works nice. The current CVS doesn't permit mapping when you want to use a system password. instead of having to give everyone separate CVS passwords or copy their system passwords into CVSROOT/passwd and then having to worry about keeping them in sync. Second, I'd like to interpret "*" in the username field as "any system user". That would allow even more simplification -- for example: *:*:cvsuser I'm a little hesitant on this one. Often repository owners want to limit access. could be used to allow any system user to run CVS; or *:asdfghjklqwer:nobody could be used to allow anyone who knows the password to run CVS. An interesting side-effect of these changes is that the SystemAuth config option would no longer be needed: *:* is equivalent to SystemAuth=yes, and *:x (or any other impossible password) is equivalent to SystemAuth=no. This has the added advantage of keeping all the password-related stuff in one place. Hummm. This is an interesting side effect. I need to think a bit more on this one. My $0.02, Mike Sutton | public class SAIC | software_failure : management_failure Beavercreek, OH | [EMAIL PROTECTED] | These are MY opinions, not SAIC's
RE: CVSROOT/passwd enhancements
Title: RE: CVSROOT/passwd enhancements Aside from any technical issues, doesn't a * in the password field of the password file typically indicate a locked account? I realize that the CVSROOT/passwd is a different file and format but it obviously has roots to /etc/passwd. There might something to be said for maintaining that convention and not confuse the issue. -- Tony Cleveland Development Manager - MicroStation Schematics Bentley Systems, Incorporated voice: (301)926-0802 fax: (301)926-2313 email: [EMAIL PROTECTED] -- -Original Message- From: Chris Cameron [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 23, 2000 6:11 PM To: 'Larry Jones'; [EMAIL PROTECTED] Subject: RE: CVSROOT/passwd enhancements On Wednesday, May 24, 2000 7:40 AM, Larry Jones [SMTP:[EMAIL PROTECTED]] wrote: I'm considering making some enhancements to the CVSROOT/passwd file format and I'd like people's opinions: First, I'd like to interpret * in the password field as the system password for this user. That would allow people who are not concerned with network security to use system passwords along with user mapping. For example, one could have a CVSROOT/passwd that looked like: john:*:cvsadmin lisa:*:cvsadmin bill:*:cvsuser anne:*:cvsuser instead of having to give everyone separate CVS passwords or copy their system passwords into CVSROOT/passwd and then having to worry about keeping them in sync. Second, I'd like to interpret * in the username field as any system user. That would allow even more simplification -- for example: *:*:cvsuser could be used to allow any system user to run CVS; or *:asdfghjklqwer:nobody could be used to allow anyone who knows the password to run CVS. An interesting side-effect of these changes is that the SystemAuth config option would no longer be needed: *:* is equivalent to SystemAuth=yes, and *:x (or any other impossible password) is equivalent to SystemAuth=no. This has the added advantage of keeping all the password-related stuff in one place. We went to the password file because cvs running as any user except root couldn't read the shadow file to verify passwords. This would not change the logic of your changes, but it could reduce the applicability. *** Chris Cameron Open Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680 New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
Re: CVSROOT/passwd enhancements
When I first studied Unix a few years ago, I read that one should use an asterisk to denote an impossible (i.e. unusable) password because asterisks are not in the set of ciphertext characters used by the Unix password encryption scheme. On our Red Hat Linux and Solaris systems, "x" is used in the password file to indicate that the password is located in the shadow file. Also, "NP" is often used to denote an impossible password. --Avi Larry Jones wrote: Tony Cleveland writes: Aside from any technical issues, doesn't a "*" in the password field of the password file typically indicate a locked account? It's what's traditionally used in /etc/passwd when shadow passwords are in use; this usage seems analogous -- "the password is not here, it is stored elsewhere". It *does* have the convenient property of being an impossible password string, so if the "somewhere else" doesn't exist or doesn't contain a password for this particular user, the account is automatically disabled. Most people I know use "x" (which is also an impossible password string) for intentionally disabled accounts.
Re: CVSROOT/passwd enhancements
On Wed, May 24, 2000 at 03:54:11PM -0400, Avi Green wrote: When I first studied Unix a few years ago, I read that one should use an asterisk to denote an impossible (i.e. unusable) password because asterisks are not in the set of ciphertext characters used by the Unix password encryption scheme. Shouldn't make any difference. The output of any given system's crypt() function is a constant-length string. If the password field is a different length, then no cleartext string can possibly encrypt to it. Also, "NP" is often used to denote an impossible password. Which is why this is safe. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / to me, Charlie Brown represented the courage to be sincere in the face of ridicule. he was NOT a loser. thank you, Mr. Schulz. - Robert C. Mayo
CVSROOT/passwd enhancements
I'm considering making some enhancements to the CVSROOT/passwd file format and I'd like people's opinions: First, I'd like to interpret "*" in the password field as "the system password for this user". That would allow people who are not concerned with network security to use system passwords along with user mapping. For example, one could have a CVSROOT/passwd that looked like: john:*:cvsadmin lisa:*:cvsadmin bill:*:cvsuser anne:*:cvsuser instead of having to give everyone separate CVS passwords or copy their system passwords into CVSROOT/passwd and then having to worry about keeping them in sync. Second, I'd like to interpret "*" in the username field as "any system user". That would allow even more simplification -- for example: *:*:cvsuser could be used to allow any system user to run CVS; or *:asdfghjklqwer:nobody could be used to allow anyone who knows the password to run CVS. An interesting side-effect of these changes is that the SystemAuth config option would no longer be needed: *:* is equivalent to SystemAuth=yes, and *:x (or any other impossible password) is equivalent to SystemAuth=no. This has the added advantage of keeping all the password-related stuff in one place. -Larry Jones You know how Einstein got bad grades as a kid? Well MINE are even WORSE! -- Calvin
RE: CVSROOT/passwd enhancements
On Wednesday, May 24, 2000 7:40 AM, Larry Jones [SMTP:[EMAIL PROTECTED]] wrote: I'm considering making some enhancements to the CVSROOT/passwd file format and I'd like people's opinions: First, I'd like to interpret "*" in the password field as "the system password for this user". That would allow people who are not concerned with network security to use system passwords along with user mapping. For example, one could have a CVSROOT/passwd that looked like: john:*:cvsadmin lisa:*:cvsadmin bill:*:cvsuser anne:*:cvsuser instead of having to give everyone separate CVS passwords or copy their system passwords into CVSROOT/passwd and then having to worry about keeping them in sync. Second, I'd like to interpret "*" in the username field as "any system user". That would allow even more simplification -- for example: *:*:cvsuser could be used to allow any system user to run CVS; or *:asdfghjklqwer:nobody could be used to allow anyone who knows the password to run CVS. An interesting side-effect of these changes is that the SystemAuth config option would no longer be needed: *:* is equivalent to SystemAuth=yes, and *:x (or any other impossible password) is equivalent to SystemAuth=no. This has the added advantage of keeping all the password-related stuff in one place. We went to the password file because cvs running as any user except root couldn't read the shadow file to verify passwords. This would not change the logic of your changes, but it could reduce the applicability. *** Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
Re: CVSROOT/passwd enhancements
Does anyone know how hard it would be to implement a PAM interface? That should leave things pretty extensible... Derek -- Derek Price CVS Solutions Architect mailto:[EMAIL PROTECTED] OpenAvenue ( http://www.OpenAvenue.com ) -- Life in a vacuum sucks. Chris Cameron wrote: On Wednesday, May 24, 2000 7:40 AM, Larry Jones [SMTP:[EMAIL PROTECTED]] wrote: I'm considering making some enhancements to the CVSROOT/passwd file format and I'd like people's opinions: First, I'd like to interpret "*" in the password field as "the system password for this user". That would allow people who are not concerned with network security to use system passwords along with user mapping. For example, one could have a CVSROOT/passwd that looked like: john:*:cvsadmin lisa:*:cvsadmin bill:*:cvsuser anne:*:cvsuser instead of having to give everyone separate CVS passwords or copy their system passwords into CVSROOT/passwd and then having to worry about keeping them in sync. Second, I'd like to interpret "*" in the username field as "any system user". That would allow even more simplification -- for example: *:*:cvsuser could be used to allow any system user to run CVS; or *:asdfghjklqwer:nobody could be used to allow anyone who knows the password to run CVS. An interesting side-effect of these changes is that the SystemAuth config option would no longer be needed: *:* is equivalent to SystemAuth=yes, and *:x (or any other impossible password) is equivalent to SystemAuth=no. This has the added advantage of keeping all the password-related stuff in one place. We went to the password file because cvs running as any user except root couldn't read the shadow file to verify passwords. This would not change the logic of your changes, but it could reduce the applicability. *** Chris CameronOpen Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
