Date: Mon, 15 Oct 2001 12:10:02 -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: <200110151910.f9FJA2G33888@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: yar@FreeBSD.org Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/15478: incorrect utmp/wtmp records update upon connection being interrupted Date: Mon, 15 Oct 2001 15:06:15 -0400 (EDT) > From yar@snark.rinet.ru Fri Oct 12 05:40:00 2001 > Date: Fri, 12 Oct 2001 13:39:57 +0400 > From: Yar Tikhiy <yar@FreeBSD.org> > To: Igor Roshchin <str@giganda.komkon.org> > Cc: freebsd-gnats-submit@FreeBSD.org > Subject: Re: kern/15478: incorrect utmp/wtmp records update upon connection being interrupted > > 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. screen used to do that (dead utmp records) on 3.x systems, I am not sure, I think it doesn't do it on 4.x any more. Note, that it was the utmp record for the actual login tty that was left behind. > > > 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. That's true with the screen, not with the xterm. Besides, I'd prefer to see the actual activity of the people logged on as I can do with the suid bit on. > > > 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 my previous response I suggested what init can do about it. You are coming from the position "in the current design of the system it can not be done". So, sometimes the design of the system can/should be changed. Again, let me reiterate my suggestion: When the init regains control of the tty, it should 1. lookup what is going on with the record corresponding to that tty in wtmp. 2. If that record does not have the corresponding "closing record", check for the existence of the utmp record a) if present - "move" it to the wtmp b) if absent - write the "closing record" to wtmp using the current time stamp. This way the system can insure that no matter what application has left a trace behind it, the wtmp and utmp files are coherent. I haven't checked how (if at all) cleaning of a dead utmp record was implemented on the way from 3.x to 4.x. That might be a part of the procedure for 2a) branch of the above. > > > 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. As we know this is not only screen problem. xterm and rxvt (and maybe something else) also does it. That's why I am suggesting to do have a universal fix from the system side. > > I'd like to repeat once more: The problem hardly can be fixed > in FreeBSD itself. I offered a possible scenario. > > > 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? yes, that was a typo. > > 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. It's time to update that logic! > 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. I believe all programs which are taking a tty from init(1) (or one of its children) should add records to utmp. Igor 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?200110151910.f9FJA2G33888>