Subject: lib/18229: spontaneous getlogin() corruption
To: None <>
From: None <>
List: netbsd-bugs
Date: 09/07/2002 22:00:23
>Number:         18229
>Category:       lib
>Synopsis:       getlogin() suddenly returns a different username
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 07 19:01:00 PDT 2002
>Originator:     Ed Ravin
>Release:        NetBSD 1.5.2
Ed Ravin
Systems Administrator
PANIX - Public Access Networks Corporation  ---
(212) 741 4400          "Please state the nature of the network emergency..."
System: NetBSD 1.5.2 NetBSD 1.5.2 (PANIX-USER) #0: Wed Jan 23 21:17:38 EST 2002 i386

Every now and then, a process suddenly finds that getlogin() is returning
a different username that the one that is supposed to own that process.
We first noticed it when mail from /usr/sbin/cron identified itself
as being from another user.  When we restarted cron the problem
went away, but later that week it recurred when a host was rebooted.
It seemed to happen on two of our three heavily-used user hosts.

We confirmed that getlogin was at fault by having cron run this script:

  perl -e 'print getlogin(), "\n";'

The problem happened once to inetd on another host, then again on one of
our public user hosts.  In this case, the user affected was a staffer
so we left the session open and wrote a short C program that dumped
out some information:

>         uid: scb
>         effective uid: scb
>         getlogin:elflord

We've ruled out any action via "su" or the "login" command - our
staffer, "scb", doesn't know "elflord" and wouldn't have tried to
switch to his account.  Furthermore, when it happened at
startup to a couple of machines, the username that getlogin()
returned for cron seemed almost random.


No clue.  It comes and goes mysteriously and thankfully, infrequently.
We haven't seen it yet on our 1.6 candidate box, but that doesn't
see as much use as our other hosts.


I only know of workarounds: If the problem is in a system daemon, the
workaround is to login as root and restart the daemon.  When it happens
to a user session, the affected user can log out and back in again.