🚀 go-pugleaf

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

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.

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 !

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.

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

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

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!

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