ejc@boole.acc.virginia.edu (Elizabeth Cummings) (10/14/87)
We noticed the following bug the other day with some of our 3b2's.
When /dev/syscon is linked to a tty line, say tty11, you can't run the
passwd command on that tty line without giving passwd an argument. This
caused major problems for people with new accounts ( we put ",.." in the
password field of all new accounts) and these people were unable to log in
on tty11.
Does anyone know why this happens? When you break the link to
/dev/syscon everthing is back to normal. (/dev/syscon was linked to
/dev/tty11 because we has taken the machine down to single user mode
from that port rather than the console. We thought that it would have
been linked back to /dev/console when rebooted.)
--
Elizabeth Cummings
University of Virginia Academic Computing Centerwescott@sauron.Columbia.NCR.COM (Mike Wescott) (10/16/87)
In article <298@boole.acc.virginia.edu> ejc@boole.acc.virginia.edu (Elizabeth Cummings) writes: > > We noticed the following bug the other day with some of our 3b2's. > When /dev/syscon is linked to a tty line, say tty11, you can't run the > passwd command on that tty line without giving passwd an argument. > > Does anyone know why this happens? passwd (without arguments) is looking in /etc/utmp to find who is logged in. It does this by checking to see which tty it has been invoked on and finds /dev/syscon. /dev/syscon has an entry in /etc/utmp (probably a dead one) and passwd gets confused. An easy workaround is to reorder your /dev directory so that /dev/syscon and /dev/systty are after all of the /dev/tty?? entries with no unused entries before the last tty?? entry. -- -Mike Wescott wescott@ncrcae.Columbia.NCR.COM
tel@moby.UUCP (Tom Lowe) (10/19/87)
In article <933@sauron.Columbia.NCR.COM>, wescott@sauron.Columbia.NCR.COM (Mike Wescott) writes: > In article <298@boole.acc.virginia.edu> ejc@boole.acc.virginia.edu (Elizabeth Cummings) writes: > > > > We noticed the following bug the other day with some of our 3b2's. > > When /dev/syscon is linked to a tty line, say tty11, you can't run the > > passwd command on that tty line without giving passwd an argument. > > > > Does anyone know why this happens? > > passwd (without arguments) is looking in /etc/utmp to find who is logged in. > It does this by checking to see which tty it has been invoked on and finds > /dev/syscon. /dev/syscon has an entry in /etc/utmp (probably a dead one) > and passwd gets confused. Close...but actually, in /etc/utmp there is an entry for tty11 which is as it should be because that is what the getty or uugetty knew about. It is NOT a dead entry....it is very much accurate and up to date. However, any process that you have running knows its controlling tty only by it's major and minor numbers. When 'passwd' runs, it calls getlogin() which looks in /etc/utmp for the login name. It first uses the major and minor number of its controlling tty to scan the /dev directory for the device it is on. The first match it finds is syscon. It tries to find syscon in /etc/utmp, but doesn't find it....Therefore it asks for the argument. You can see this in action by doing a ps -ef and noticing that the tty for your processes are syscon and not tty11. Also if you do an 'od' of /etc/utmp you will see tty11 and not syscon. Also do a 'od' of the /dev directory and you will see the order of the entries. > > An easy workaround is to reorder your /dev directory so that /dev/syscon and > /dev/systty are after all of the /dev/tty?? entries with no unused entries > before the last tty?? entry. This is true...you can use fsdb to change this around. > -- > -Mike Wescott > wescott@ncrcae.Columbia.NCR.COM -- Tom Lowe {rutgers,gatech,huscb,burdvax,ihnp4,cbosgd}!psuvax1!moby!tel AT&T National Systems Support Center, S. Plainfield, NJ (1-800-922-0354) Please call only if you have an AT&T computer under Warranty or if you have an AT&T Maintenance Contract on your equipment.
jpp@slxsys.co.uk (John Pettitt) (10/23/87)
In article <298@boole.acc.virginia.edu> ejc@boole.acc.virginia.edu (Elizabeth Cummings) writes: > We noticed the following bug the other day with some of our 3b2's. >When /dev/syscon is linked to a tty line, say tty11, you can't run the >passwd command on that tty line without giving passwd an argument. This >caused major problems for people with new accounts ( we put ",.." in the >password field of all new accounts) and these people were unable to log in >on tty11. ",.." in /etc/passwd ! I hope you dont allow dial'ins now you have told the world ! The /dev/syscon problem also shows up on our V.3/386 system (Interactive Systems 386ix). We set the default prompt to 'nodename!userid ' in /etc/profile. When we had /dev/syscon linked to /dev/vt01 'who am i' failed to return anything although 'tty' and 'id' and who -a all worked. Is this a bug or a feature and if it is a feature what is going on ? -- John Pettitt G6KCQ, CIX jpettitt, Voice +44 1 398 9422 UUCP: ...uunet!mcvax!ukc!pyrltd!slxsys!jpp (jpp@slxsys.co.uk) Disclaimer: I don't even own a cat to share my views !
kimcm@ambush.UUCP (Kim Chr. Madsen) (10/26/87)
In article <260@slxsys.co.uk> jpp@slxsys.co.uk (John Pettitt) writes: >",.." in /etc/passwd ! I hope you dont allow dial'ins now you have told >the world ! That is ridiculous all password fields under 13 characters are void - that means if you put a password entry of NOLOGIN you cannot login under that username. Only if the encrypted password is exactly 13 characters long will it be accepted as an encrypted password. Kim Chr. Madsen.
ronald@csuchico.EDU (Ronald Cole) (10/29/87)
In article <260@slxsys.co.uk>, jpp@slxsys.co.uk (John Pettitt) writes: > In article <298@boole.acc.virginia.edu> ejc@boole.acc.virginia.edu (Elizabeth Cummings) writes: > > ( we put ",.." in the > >password field of all new accounts) > > ",.." in /etc/passwd ! I hope you dont allow dial'ins now you have told > the world ! Since I didn't see a smiley, I thought I might explain. I believe Elizabeth was referring to the practice of appending ",.." to the encrypted password in new user's entries in the /etc/passwd file. This causes the password to be expired the next time that a user logs onto the system. Here at CSU, Chico, new users fill out forms with their login and password and these are kept on file. Having the user change their password the first time they log in ensures that their password is secure (should someone break into the computer room and leaf through the file of account forms). I believe that this is a more secure management technique than just giving new users no at all! -- Ronald Cole | uucp: ihnp4!csun!csuchic!ronald AT&T 3B5 System Manager | PhoneNet: ronald@csuchico.edu California State University, Chico | voice (916) 895-4635 "... and if you don't like it, you must lump it." -Joseph Smith
dpb@tellab5.UUCP (11/02/87)
Within Article <538@ambush.UUCP> kimcm@ambush.UUCP (Kim Chr. Madsen) writes: +In article <260@slxsys.co.uk> jpp@slxsys.co.uk (John Pettitt) writes: +>",.." in /etc/passwd ! I hope you dont allow dial'ins now you have told +>the world ! + +That is ridiculous all password fields under 13 characters are void - +that means if you put a password entry of NOLOGIN you cannot login +under that username. Only if the encrypted password is exactly 13 +characters long will it be accepted as an encrypted password. + + Kim Chr. Madsen. Ok, Kim your right for BSD and USG up until System III, but from System III on and their mutations the encrypted password field has a subfield comma delimited that is used for password aging. It is incoded in radix64 and the first digit is how often the user must change their password the second digit is minimum number of weeks between password changes. -- ################################################################################ Thanks, Darryl Baker ihnp4!tellab5!dpb
allbery@ncoast.UUCP (Brandon Allbery) (11/03/87)
As quoted from <538@ambush.UUCP> by kimcm@ambush.UUCP (Kim Chr. Madsen): +--------------- | In article <260@slxsys.co.uk> jpp@slxsys.co.uk (John Pettitt) writes: | >",.." in /etc/passwd ! I hope you dont allow dial'ins now you have told | >the world ! | | That is ridiculous all password fields under 13 characters are void - +--------------- Yes, Kim, All the World is a Vax Running 4.3BSD.... We are talking about UNIX SYSTEM V. Not BSD. UNIX SYSTEM V has a system called "password aging". "login" and "su" both know that a 13-character encrypted password may optionally be followed by a comma and two or four characters from the set [A-Za-z0-9/.]. The first two characters indicate the maximum time between password changes; the other two represent the date of the last password change. The two-letter values are weeks encoded in base 64 via the library routines a64l() and l64a(). Please excuse the tone of this message, but I'm mighty SICK of BSD types posting on the net that something in System V but not in BSD OBVIOUSLY DOES NOT EXIST AT ALL because it's not in BSD. Come off it. I don't go around posting snide remarks about how System V is "obviously superior". Why should you ("you" meaning collectively all the BSD'ers who so post). [I'll let you in on a secret: NEITHER is perfect. System V has stuff that BSD needs badly; on the other hand, job control would be mighty handy under System V. And symlinks are a good example of a no-win: System V doesn't have them, but they are handy; BSD has them, but they're capable of causing major (and minor) problems. A whole month of Usenet brainstorming came up with no real solution. Conclusion: both need work. Don't glorify what ain't glorious.] -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {harvard!necntc,well!hoptoad,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery "Uncle _who_?" -- Lt. Worf ^^^^^^^^^^^^^ NOTE NEW PATH!
chris@mimsy.UUCP (Chris Torek) (11/05/87)
In article <886@csuchic.csuchico.EDU> ronald@csuchico.EDU (Ronald Cole) writes: >",.." ... causes the password to be expired the next time that a >user logs onto the system. ... new users fill out [paper] forms with >their login and password and these are kept on file. We have a program called `newacct' that builds most of the passwd file entry, including the encrypted password, in such a way so that the unencrypted password is not stored anywhere. Such a program is easy to write, given the existence of getpass() and crypt(). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris