>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
>Closed-Date:
>Last-Modified:
>Originator:     Ed Ravin
>Release:        NetBSD 1.5.2
>Organization:
Ed Ravin
Systems Administrator
PANIX - Public Access Networks Corporation  ---  http://www.panix.com
(212) 741 4400          "Please state the nature of the network emergency..."
>Environment:
System: NetBSD panix2.panix.com 1.5.2 NetBSD 1.5.2 (PANIX-USER) #0: Wed Jan 23 21:17:38 EST 2002 marcotte@trinity.nyc.access.net:/devel/netbsd/1.5.2/src/sys/arch/i386/compile/PANIX-USER i386


>Description:
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.


>How-To-Repeat:

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.

>Fix:

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.
>Release-Note:
>Audit-Trail:
>Unformatted: