On Feb 25,  9:05am, i18rabbit@cwazy.co.uk (i18rabbit@cwazy.co.uk) wrote:
-- Subject: Re: bin/32903: utmp remains empty

| The following reply was made to PR bin/32903; it has been noted by GNATS.
| 
| From: i18rabbit@cwazy.co.uk
| To: gnats-bugs@netbsd.org
| Cc: 
| Subject: Re: bin/32903: utmp remains empty
| Date: Sat, 25 Feb 2006 09:06:00 GMT
| 
|  >  >  login(1) is run with root privileges.
|  >  >  if it wants to write to a file, it can
|  >  >  do so.  the problem is that it is not
|  >  >  writing to the utmp file as it should.
|  >  >  it would seem to me the problem is with
|  >  >  the login source code - maybe it wasn't
|  >  >  compiled with a "UTMP" preprocessor
|  >  >  variable defined or something.  i don't
|  >  >  see how it has anything to do with groups
|  >  >  or permissions - this solution seems like
|  >  >  a wild goose chase. ?
|  > 
|  >  login drops its root privileges after you log in. And it seems to me that
|  >  if utmp entries are created for everyone except you, the problem must not
|  >  be in the login source code.
|  
|  utmp entries are created by ssh logins and reboots/shutdowns,
|  but not for *any* console or telnet logins.  this is the problem.
|  
|  >  You still haven't answered why your system didn't have a "utmp" group,
|  >  and why your file permissions were incorrect.
|  
|  because i maintain several BSD systems, and i have
|  a stripped custom /etc directory that i use for
|  all of them; for ease of set-up and maintenance.
|  
|  > Seeing that NetBSD has come with a utmp group for over a decade, the fact
|  > that you didn't have one points to a problem in your install. Maybe the
|  > incorrect permissions are unrelated, but you should look at your install
|  > first, not the source code. If not permissions, maybe your pam configuration
|  > is messed up (pam_lastlog.so not being used).
|  
|  reboots+shutdowns and sshd make correct utmp entries.
|  login and telnetd do not.  i would like to know if
|  there is a "manual" test i can do to isolate
|  the problem.

For login and telnet logging is done by the pam_lastlog module. It syslogs
on error. Pam lastlog cannot fail because /etc/pam.d/system contains:

session         required        pam_lastlog.so          no_fail no_nested

If you take out the no_fail, then you might not be able to login anymore,
but at least you'll know it is failing. Do you have

/usr/lib/security/pam_lastlog.so.0?

christos