From owner-freebsd-bugs Fri Oct 12 2:50:11 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 35D4637B405 for ; Fri, 12 Oct 2001 02:50:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f9C9o1o53717; Fri, 12 Oct 2001 02:50:01 -0700 (PDT) (envelope-from gnats) Date: Fri, 12 Oct 2001 02:50:01 -0700 (PDT) Message-Id: <200110120950.f9C9o1o53717@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Yar Tikhiy Subject: Re: kern/15478: incorrect utmp/wtmp records update upon connection being interrupted Reply-To: Yar Tikhiy 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: Yar Tikhiy To: Igor Roshchin Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/15478: incorrect utmp/wtmp records update upon connection being interrupted Date: Fri, 12 Oct 2001 13:39:57 +0400 On Thu, Oct 11, 2001 at 12:33:27PM -0400, Igor Roshchin wrote: > > 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. Does screen produce such dead utmp records? I interpreted your message that it was rxvt that caused the "zombie" records in utmp. > Removing the set-uid bit is not a good thing. It prevents you from seeing > the users on the computer with w(1). No it doesn't. If you remove the suid bit from screen, you'll just see a user's initial login instead of his screen sessions. > 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. I don't see a clear way of fixing the wtmp file in such a case. Additionally, I believe an operating system cannot have a tool/code to fix every breakage that a lame program run with the superuser rights may introduce. > 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). init, sshd, and telnetd effectively move a utmp record from the utmp file to the wtmp file. If there's no record in the utmp file for the tty, these programs can do nothing about fixing the wtmp file. And screen removes the utmp record for the user when started. If screen didn't, the problem wouldn't appear at all. > Again, the part "2" of the initial PR > might've been fixed in the recent releases. I'd like to repeat once more: The problem hardly can be fixed in FreeBSD itself. > 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 ? ^^^^ wtmp? The actual init's (and sshd's, and telnetd's) logic is opposite to what you propose: init won't add a logout record to wtmp if there is no record in utmp for the tty by the time of a logout. That's because programs run by init don't need to record logins to utmp--some of them may have to do nothing with logins/logouts. > 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) Sorry, but I couldn't reproduce that. Would you mind sending me an example of such wtmp in a personal mail? -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message