jdp@PacBell.COM (Jerry D. Pierce) (12/27/89)
I'm running 386/ix (version 2.0.2) on a Compaq 386/20e and I have a couple of questions in regards to shadow passwording. On other systems I administer, I pretty much keep the password file in UID (numeric) order by directly editting the file with vi. However, with shadow passwords in place, I am more than a little leery to try this. Anyone have any suggestions?? Keeping the /etc/passwd & /etc/shadow entries in numeric order makes the task of administering the boxes much easier... I also remember reading awhile back in the AT&T release notes for a 3B2/700 I was upgrading, something about "shadow passwording is not compatible with all applications, the general symptom is you will not be able to log into the machine." Or something similar. Anyone had any problems?? Jerry Pierce pacbell!pbhyf!jdp
cpcahil@virtech.uucp (Conor P. Cahill) (12/27/89)
In article <6637@pbhyf.PacBell.COM>, jdp@PacBell.COM (Jerry D. Pierce) writes: > I'm running 386/ix (version 2.0.2) on a Compaq 386/20e and I have a > couple of questions in regards to shadow passwording. On other systems > I administer, I pretty much keep the password file in UID (numeric) > order by directly editting the file with vi. However, with shadow > passwords in place, I am more than a little leery to try this. Anyone > have any suggestions?? Keeping the /etc/passwd & /etc/shadow entries > in numeric order makes the task of administering the boxes much > easier... Using vi (or any other program) to edit, sort, or do whatever else you might want to do with /etc/passwd and /etc/shadow has the same limitations whether or not the shadow file is used. I manually add each user to the passwd file and then the shadow file using vi all the time. You only run into problems when somebody else is doing something with the passwd/shadow file at the same time you are editing the file. > I also remember reading awhile back in the AT&T release notes for a > 3B2/700 I was upgrading, something about "shadow passwording is not > compatible with all applications, the general symptom is you will > not be able to log into the machine." Or something similar. Anyone > had any problems?? The problem is that if you have another program that is used to getting the password out of /etc/passwd it will have to be modified to look for the password in /etc/shadow. All of the system utilities in 2.0.2 use the /etc/shadow file (this includes login, passwd, telnet, and rlogin) -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
hoffman@wrdso.ATT.DSO (Paul Hoffman) (12/28/89)
In article <6637@pbhyf.PacBell.COM>, jdp@PacBell.COM (Jerry D. Pierce) writes: > couple of questions in regards to shadow passwording...I pretty much keep > the password file in UID (numeric) order by directly editting... > I am more than a little leery to try this. > I also remember reading awhile back in the AT&T release notes for a > 3B2/700 I was upgrading, something about "shadow passwording is not > compatible with all applications, the general symptom is you will > not be able to log into the machine." Or something similar. Anyone > had any problems?? See if you have a command "/usr/bin/pwconv". On Sys V Rel 3.2.1 & 3.2.2 this will rebuild your shadow file to match your password file. The documentation warns against directly editing /etc/passwd, but then tells you if you do to rerun /etc/pwconv to ensure there is no incompatibility between the two. I have been doing this for over a year w/ no trouble. Re: incompatibility: The only thing which broke when I converted to running /etc/shadow was remote login authorization over a fiber interface to a DATAKIT VCS node. Newer interface software on the 3B solved that. (I didn't care much anyway...the users could still get in through the login prompt over the fiber...They just could not map themselves directly into their login on this system automatically.) If you decide against shadow, the command "/usr/bin/pwunconv" goes back to having encrypted password info in /etc/passwd. Paul Hoffman
weave@sun.acs.udel.edu (Ken Weaverling) (12/28/89)
In article <6637@pbhyf.PacBell.COM> jdp@PacBell.COM (Jerry D. Pierce) writes: > >I also remember reading awhile back in the AT&T release notes for a >3B2/700 I was upgrading, something about "shadow passwording is not >compatible with all applications, the general symptom is you will >not be able to log into the machine." Or something similar. Anyone >had any problems?? > Yes, I had that problem when we switched from Sys V 3.0 to 3.1 a while back. A PC file server application by Locus (PC-Interface version 2.8.7) broke. Basically, it allows DOS users access to the UNIX file system as a DOS drive and does its own user validation during its login. Obviously, when user phredd entered his password, PC-Interface was looking for the password in passwd and not shadow. The result was that there were a lot of angry dos users at me. (eh, so what... :-) Anyway, the warning is a valid one if you have any software that does its own user validation with passwords. I just wish the warning you mentioned was in *MY* manual as well! The fix was to get version 2.8.7.1 :-) (No, for real, weird version #s!!) -- Ken Weaverling - Systems Administrator | Internet: 00499@vax1.acs.udel.edu Delaware Technical & Community College | Voice: +1 302 573 5460
jdp@PacBell.COM (Jerry D. Pierce) (12/29/89)
In article <185@wrdso.ATT.DSO> hoffman@wrdso.ATT.DSO (Paul Hoffman) writes: >See if you have a command "/usr/bin/pwconv". On Sys V Rel 3.2.1 & 3.2.2 this >will rebuild your shadow file to match your password file. The documentation >warns against directly editing /etc/passwd, but then tells you if you do to >rerun /etc/pwconv to ensure there is no incompatibility between the two. >I have been doing this for over a year w/ no trouble. Great! I'll use pwconv to keep the files clean and kosher, since I can't un-do shadow passwords... >If you decide against shadow, the command "/usr/bin/pwunconv" goes back to >having encrypted password info in /etc/passwd. Unfortunately, I can't find pwuncov in my Interactive package. Anybody out there at Interactive care to comment? >Paul Hoffman I've received a number of e-mail responses to my query about shadow passwords, and about half of them have experienced problems running under shadow passwords. (Appears that any programs which try to access a user password directly from /etc/password don't function correctly, which does make sense.) Since a number of packages don't support shadow passwording, I think that pwunconv SHOULD have been included in the release. (2.0.2) Thanks to everyone for the assistance! Jerry Pierce pacbell!pbhyf!jfp
mike@antel.uucp (Michael Borza) (12/29/89)
In article <1989Dec27.125642.3097@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >In article <6637@pbhyf.PacBell.COM>, jdp@PacBell.COM (Jerry D. Pierce) writes: >> I also remember reading awhile back in the AT&T release notes for a >> 3B2/700 I was upgrading, something about "shadow passwording is not >> compatible with all applications, the general symptom is you will >> not be able to log into the machine." Or something similar. Anyone >> had any problems?? > >The problem is that if you have another program that is used to getting >the password out of /etc/passwd it will have to be modified to look for >the password in /etc/shadow. All of the system utilities in 2.0.2 >use the /etc/shadow file (this includes login, passwd, telnet, and rlogin) I know of at least rexec which still doesn't get it right. Rexec'ing from 2.0.2 to 1.0.6 works just fine; going the other way fails because the password validation fails. This was also broken in 2.0.1, which I reported to my vendor. I had hoped, but didn't really expect, that it would be fixed in 2.0.2. Maybe in 2.2? mike borza. -- Michael Borza Antel Optronics Inc. (416)335-5507 3325B Mainway, Burlington, Ont., Canada L7M 1A6 work: mike@antel.UUCP or uunet!utai!utgpu!maccs!antel!mike home: mike@boopsy.UUCP or uunet!utai!utgpu!maccs!boopsy!mike