misc/75378: login/wtmp/utmp not updating properly

Brandon Lodriguss brandon at elitenj.net
Tue Dec 21 20:20:25 PST 2004


>Number:         75378
>Category:       misc
>Synopsis:       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:
>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 at 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:
>Unformatted:


More information about the freebsd-bugs mailing list