From bml@core.elitenj.net  Wed Dec 22 04:13:06 2004
Return-Path: <bml@core.elitenj.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 4F18516A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 22 Dec 2004 04:13:06 +0000 (GMT)
Received: from core.elitenj.net (core.elitenj.net [64.253.60.18])
	by mx1.FreeBSD.org (Postfix) with ESMTP id AFB3343D4C
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 22 Dec 2004 04:13:05 +0000 (GMT)
	(envelope-from bml@core.elitenj.net)
Received: from core.elitenj.net (bml@localhost.elitenj.net [127.0.0.1])
	by core.elitenj.net (8.13.1/8.13.1) with ESMTP id iBM4D2YU060792
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 21 Dec 2004 23:13:02 -0500 (EST)
	(envelope-from bml@core.elitenj.net)
Received: (from bml@localhost)
	by core.elitenj.net (8.13.1/8.13.1/Submit) id iBM4D2Jp060791;
	Tue, 21 Dec 2004 23:13:02 -0500 (EST)
	(envelope-from bml)
Message-Id: <200412220413.iBM4D2Jp060791@core.elitenj.net>
Date: Tue, 21 Dec 2004 23:13:02 -0500 (EST)
From: Brandon Lodriguss <brandon@elitenj.net>
Reply-To: Brandon Lodriguss <brandon@elitenj.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: login/wtmp/utmp not updating properly
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         75378
>Category:       bin
>Synopsis:       login(1): login/wtmp/utmp not updating properly
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Dec 22 04:20:24 GMT 2004
>Closed-Date:    
>Last-Modified:  Thu Dec 17 04:00:05 UTC 2009
>Originator:     Brandon Lodriguss
>Release:        FreeBSD 5.3-RELEASE i386
>Organization:
>Environment:
System: FreeBSD core.elitenj.net 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Dec 10 23:03:51 EST 2004 bml@core.elitenj.net:/usr/src/sys/i386/compile/SIGINT i386
	CPU: Pentium III/Pentium III Xeon/Celeron (501.14-MHz 686-class CPU)
	real memory  = 536854528 (511 MB)
	avail memory = 519864320 (495 MB)

>Description:
Running the login program from a remote shell in order to log in a second time
"locally" fails to properly update utmp/wtmp.
If you log in via ssh, then log in again manually by running the login program
then log out of that second shell, utmp/wtmp seems to have totally forgotten
your original environment, because you are no longer listed in a w or a who,
and doing last (username) does not return that the user is still logged in.

I have posted to freebsd-questions and have found several other people running
5.3-RELEASE who can reproduce this problem.  I have spoken with a 4.10 and
5.3-STABLE administrator who cannot reproduce the problem on those systems.
No one on the lists has been able to explain or attribute to a config error.
The only way to see connected users in this invisible state is to view open
sockets, count running sshd processes, or snoop on the tty the user happens
to be on (which you can figure out from the sshd process.)

As you will see below, insofar as the wtmp/utmp records go, running the login
program seems to totally discard the initial login environment as if the user 
had logged out completely.  

One person on fbsd-questions suggested this was expected behavior for the 
login program, since the man page says by default login discards any previous 
environment.  If this were truly the case, exiting the second shell should 
exit the user from the system rather than return them to a "discarded" 
environment.	

>How-To-Repeat:
Simple- (login via ssh, login locally from shell using 'login', exit, w or who)
Detailed-
Log in via ssh to a normal user shell.
Type date and note the time.
Run w or who to verify user is listed.
Wait at least one minute.
Type login and log in with same username.
Type date and note the new time.
Run w or who to verify user is still listed.
Wait at least one minute.
Type exit.
Type date and note the third time.
Run w or who - user is no longer listed.  user count is incorrect.
Run last (username).  This will show (user) logged out at the same time (user)
logs in with the 'login' command.

>Fix:

Chmod the login program so that only root can run it.  This will allow the
initial ssh login environment to get created, but not allow users to manually
execute login for a local login.
OR
Edit /etc/login.access to disallow LOCAL logins for users.

>Release-Note:
>Audit-Trail:

From: Volker <volker@vwsoft.com>
To: bug-followup@FreeBSD.org, brandon@elitenj.net
Cc:  
Subject: Re: bin/75378: login(1): login/wtmp/utmp not updating properly
Date: Mon, 03 Mar 2008 23:51:22 +0100

 Brandon,
 
 I'm unable to recreate your problem on a 6.2-R and a 7.0 box.
 
 Current behavior is now like you're describing good behavior: the first
 shell will get closed as soon as the 2nd one is exited.
 
 I'm wondering if you're still able to see the problem or if we can close
 this PR?
State-Changed-From-To: open->feedback 
State-Changed-By: vwe 
State-Changed-When: Mon Mar 3 23:15:37 UTC 2008 
State-Changed-Why:  
request confirmation from submitter to close 

http://www.freebsd.org/cgi/query-pr.cgi?pr=75378 
State-Changed-From-To: feedback->closed 
State-Changed-By: vwe 
State-Changed-When: Sat Mar 8 23:55:57 UTC 2008 
State-Changed-Why:  
mail to submitter bounces with "no route to host" -> closing this 
note to submitter: If you see this message and think it's still an issue you're seeing, please provide us with a valid email address and we'll reopen this ticket. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=75378 

From: Bruce Cran <bruce@cran.org.uk>
To: bug-followup@FreeBSD.org
Cc: vwe@freebsd.org
Subject: Re: bin/75378: login(1): login/wtmp/utmp not updating properly
Date: Sun, 30 Mar 2008 10:28:03 +0100

 This still happens on a 7.0 machine, but not when the shell is /bin/csh 
 or /bin/tcsh - if a csh is used then the first shell is closed when the 
 2nd login is exited.  If you use /bin/sh then the following is seen:
 
  > ssh box1
 Password:
 $ w
 10:21AM  up 6 days, 10:56, 1 user, load averages: 0.01, 0.02, 0.00
 USER             TTY      FROM              LOGIN@  IDLE WHAT
 user1            p0       abcd:aaa:aaa:a:b 10:21AM     - w
 $ login
 login: user1
 $ w
 10:22AM  up 6 days, 10:57, 1 user, load averages: 0.00, 0.01, 0.00
 USER             TTY      FROM              LOGIN@  IDLE WHAT
 user1            p0       -                10:22AM     - w
 $ exit
 $ w
 10:22AM  up 6 days, 10:57, 0 users, load averages: 0.00, 0.01, 0.00
 USER             TTY      FROM              LOGIN@  IDLE WHAT
 $ exit
 Connection to box1 closed.
  >
 
 --
 Bruce
 
 
State-Changed-From-To: closed->open 
State-Changed-By: vwe 
State-Changed-When: Tue Apr 1 19:52:16 UTC 2008 
State-Changed-Why:  

reopen as requested - still an issue as confirmed by Bruce 
submitter: if you see this, please give us a valid email address if you're still 
interested in this issue. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=75378 

From: Holger Kunst <hkunst@truebridge.com>
To: bug-followup@FreeBSD.org, brandon@elitenj.net
Cc:  
Subject: Re: bin/75378: login(1): login/wtmp/utmp not updating properly
Date: Wed, 16 Dec 2009 22:29:48 -0500

 I am experiencing the same problem. I am happy to provide more detail if required.
 
 The "at" command sends an email with the output of the scheduled job.
 I've experienced inconsistent results when running jobs, receiving
 emails in accounts not associated with the user currently logged in.
 
 To reproduce in FreeBSD 7.2-RELEASE-p2
 
 Case #1
 login as user a (new shell through ssh)
 echo "echo 1" | at now
 -->  user a will receive an email containing "1" - this is as expected
 
 Case #2
 login as user a (new shell through ssh)
 login as user b
 exit
 echo "echo 1" | at now
 -->  user b will receive an email containing "1" - this is not as
 expected, since I am user a again
 
 A look at the source for "at" reveals that "at" is getting the mailname
 from getlogin(). Running a small test program that outputs getlogin(),
 confirms the above behavior: A log-in and out of another account makes
 getlogin() return that account's name, even though the shell has been
 closed and we are back to the original shell and the original user a.
 
 Holger
 
>Unformatted:
