From owner-freebsd-bugs Thu Oct 11 9:40:10 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id DA8E137B403 for ; Thu, 11 Oct 2001 09:40:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f9BGe3h71115; Thu, 11 Oct 2001 09:40:03 -0700 (PDT) (envelope-from gnats) Date: Thu, 11 Oct 2001 09:40:03 -0700 (PDT) Message-Id: <200110111640.f9BGe3h71115@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Igor Roshchin Subject: Re: kern/15478: incorrect utmp/wtmp records update upon connection being interrupted Reply-To: Igor Roshchin Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/15478; it has been noted by GNATS. From: Igor Roshchin 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" > To: , > 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