Date: Thu, 11 Oct 2001 09:40:03 -0700 (PDT) From: Igor Roshchin <str@giganda.komkon.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/15478: incorrect utmp/wtmp records update upon connection being interrupted Message-ID: <200110111640.f9BGe3h71115@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/15478; it has been noted by GNATS.
From: Igor Roshchin <str@giganda.komkon.org>
To: freebsd-gnats-submit@FreeBSD.org, str@giganda.komkon.org,
yar@comp.chem.msu.su
Cc:
Subject: Re: kern/15478: incorrect utmp/wtmp records update upon connection being interrupted
Date: Thu, 11 Oct 2001 12:33:27 -0400 (EDT)
> From yar@comp.chem.msu.su Thu Oct 11 09:57:05 2001
> From: "Yar Tikhiy" <yar@comp.chem.msu.su>
> To: <freebsd-gnats-submit@FreeBSD.org>, <str@giganda.komkon.org>
> Subject: Re: kern/15478: incorrect utmp/wtmp records update upon connection being interrupted
> Date: Thu, 11 Oct 2001 17:57:08 +0400
>
> As I can see, it's hardly a FreeBSD problem. It's the consequence of some
> applications (e.g. xterm, rxvt, screen) modifying utmp bogusly.
>
> Rxvt and xterm just can't clean up if killed unconditionally.
>
> As for screen, it does a Very Bad Thing: It takes a user record out of utmp
> at startup. Of course, /sbin/init then won't add a logout record to wtmp if
> the
> session gets aborted. If I were in your shoes, I'd report that to the author
> of screen.
>
> The instant cure is to remove the set-uid bit from the programs so they
> won't
> mess utmp up.
>
> If you don't mind, I'd rather close this PR since it has to do nothing
> with FreeBSD.
>
First of all, I am not completely sure if the part "2" of the initial PR
is still happening on 4.x systems (the one concerning the utmp),
while the part 1 (concerning the wtmp) is still valid for sure.
I just don't have a conclusive evidence that the part "2" is gone completely.
In a presence of the part "2", when utmp has a record of a currently logged
user when there are no processes related to the tty in question,
your comments about screen and its behavior do not have a complete
description of the problem.
Removing the set-uid bit is not a good thing. It prevents you from seeing
the users on the computer with w(1).
Although I see your point, at this moment I am not convinced that this an
application-only problem. I believe the system should be able to correct
both utmp and wtmp. Thus, I don't think this PR should be closed without
a proper fix.
From init(8):
In multi-user operation, init maintains processes for the terminal ports
found in the file ttys(5). ..
... getty opens
and initializes the tty line and executes the login(1) program. The
login program, when a valid user logs in, executes a shell for that user.
When this shell dies, either because the user logged out or an abnormal
termination occurred (a signal), the init program wakes up, deletes the
user from the utmp(5) file of current users and records the logout in the
wtmp(5) file. The cycle is then restarted by init executing a new getty
for the line.
In the initially reported behavior, the utmp record of a user disconnected
was present until somebody else would log in onto the same tty. Then
the utmp would get cleared (by init ?), while wtmp record still wouldn't be
closed (i.e. logout record is not added).
Again, the part "2" of the initial PR
might've been fixed in the recent releases.
Regardless whether that part was fixed or not,
how about some type of check-and-cleanup procedure in init, when it
regains the ownership of the tty , and checks if there is a record
in utmp, and if not, just adds a logout record to utmp ?
Igor
PS. This wtmp-related bug reveals a bug in last(1)
Interestingly enough, last(1) , depending on the invocation,
behaves differently. Note, that "user" is no longer logged in.
machine: [12:13] [651] ~>last | grep user
user ttypi 64.152.168.61 Thu Oct 11 00:38 - 02:23 (01:44)
user ttypt 63.210.212.179 Wed Oct 10 23:19 still logged in
user ttypm 209.246.81.251 Tue Oct 9 22:00 - 22:48 (00:47)
user ttyq3 209.246.91.243 Thu Oct 4 21:33 still logged in
user ttypc 64.152.174.71 Wed Oct 3 18:13 - 18:58 (00:44)
machine: [12:13] [652] ~>
machine: [12:13] [652] ~>last -10 user
user ttypi 64.152.168.61 Thu Oct 11 00:38 - 02:23 (01:44)
user ttypt 63.210.212.179 Wed Oct 10 23:19 - 09:18 (09:59)
user ttypm 209.246.81.251 Tue Oct 9 22:00 - 22:48 (00:47)
user ttyq3 209.246.91.243 Thu Oct 4 21:33 - 17:09 (19:35)
^C
interrupted Thu Oct 4 07:19
In the second case it is reporting the logout
time of the next user (user2) logged on the same tty later:
user2 ttypt 130.91.163.208 Thu Oct 11 09:12 - 09:18 (00:06)
This is a bug in last(1)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110111640.f9BGe3h71115>