Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Jan 1997 02:39:28 +1100
From:      davidn@unique.usn.blaze.net.au (David Nugent)
To:        smorris@tsi.gte.com (Scott Morris)
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Dangling logins
Message-ID:  <Mutt.19970118023928.davidn@labs.blaze.net.au>
In-Reply-To: <1.5.4.16.19970117093905.3ddff000@uhuru.tsi.gte.com>; from Scott Morris on Jan 17, 1997 09:40:37 -0500
References:  <1.5.4.16.19970117093905.3ddff000@uhuru.tsi.gte.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Scott Morris writes:
> I've noticed that when I execute login from an X-win do my thing and
> exit last indicates "still logged in " for days. No where else can I detect
> any residue from the login. It would appear to be a cosmetic problem but I
> thought I would ask if anyone else has noted this.

Yes, this is a known problem with invoking login from a
standard shell. FWIW, I disable this capability by removing
the setuid bit since it interferes with our accounting system
when this happens. Use su(1) instead.

The problem is that login creates a record in /var/log/wtmp,
with no matching logout record for your existing login. This
isn't a problem normally, since the init->getty->login cycle
expects that there is no "current" login. last(1) won't be
able to find the logout and therefore thinks you're still
logged in and will only 'log you out' when the system next
reboots. 'w' doesn't have the same problem only because utmp
records for each tty are overwritten according to the tty
itself. If these were managed dynamically as they are in some
other operating systems, then it may well show up in there as
well.

FWIW, I would call this a bug in login(1), since it should
handle this situation by writing the "logout" record before it
handles the new login, and in fact can (and should) detect
this situation and act accordingly. Otherwise, it should be
installed without setuid which would make running login as
anyone but root ineffective (but the possibility is still
there to screw this up from the root account, of course, so
this fix just relieves the symptoms in most cases, not the
cause of the problem itself).

Regards,

David Nugent - Unique Computing Pty Ltd - Melbourne, Australia
Voice +61-3-9791-9547  Data/BBS +61-3-9792-3507  3:632/348@fidonet
davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970118023928.davidn>