Subject: Re: bin/32903: utmp remains empty
To: None <firstname.lastname@example.org, email@example.com,>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 02/25/2006 12:08:16
On Feb 25, 9:05am, email@example.com (firstname.lastname@example.org) wrote:
-- Subject: Re: bin/32903: utmp remains empty
| The following reply was made to PR bin/32903; it has been noted by GNATS.
| From: email@example.com
| To: firstname.lastname@example.org
| 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