bin/61355: login(1) does not restore terminal ownership on exit

Eitan Adler lists at eitanadler.com
Sun Apr 28 21:50:02 UTC 2013


The following reply was made to PR bin/61355; it has been noted by GNATS.

From: Eitan Adler <lists at eitanadler.com>
To: bug-followup <bug-followup at freebsd.org>
Cc:  
Subject: Re: bin/61355: login(1) does not restore terminal ownership on exit
Date: Sun, 28 Apr 2013 17:44:34 -0400

 ---------- Forwarded message ----------
 From: Jilles Tjoelker <jilles at stack.nl>
 Date: 28 April 2013 17:30
 Subject: Re: bin/61355: login(1) does not restore terminal ownership on exit
 To: freebsd-bugs at freebsd.org
 
 
 The following reply was made to PR bin/61355; it has been noted by GNATS.
 
 From: Jilles Tjoelker <jilles at stack.nl>
 To: bug-followup at FreeBSD.org, eugen at kuzbass.ru
 Cc:
 Subject: Re: bin/61355: login(1) does not restore terminal ownership on exit
 Date: Sun, 28 Apr 2013 23:23:05 +0200
 
  > [nested login(1) does not restore tty ownership]
 
  If it didn't break anything, I would like to "solve" this problem by
  removing /usr/bin/login's setuid bit. You can use su (or sudo from
  ports) to become another user temporarily.
 
  With utmpx, I think the corruption of those files is solved. The utmpx
  code can handle overlapping sessions on the same tty.
 
  The tty ownership is normally reset to root:wheel by the new getty (for
  ttys managed via /etc/ttys) or by the destruction of the tty (for pseudo
  terminals). So it is probably safe to remember the old uid/gid and
  restore it later.
 
  Even with that, there is no isolation between the two users. Since there
  is no new session or revocation (and there cannot be), the nested user
  can continue to access the tty after the "logout". For the same reason,
  the setlogin() call affects both the old and the new user's processes;
  this is not undone afterwards either.
 
  --
  Jilles Tjoelker
 _______________________________________________
 freebsd-bugs at freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
 To unsubscribe, send any mail to "freebsd-bugs-unsubscribe at freebsd.org"
 
 
 -- 
 Eitan Adler


More information about the freebsd-bugs mailing list