misc/183495: utx.active not being updated correctly
jilles at stack.nl
Wed Nov 13 23:40:01 UTC 2013
The following reply was made to PR misc/183495; it has been noted by GNATS.
From: Jilles Tjoelker <jilles at stack.nl>
To: Ed Schouten <ed at 80386.nl>
Cc: bug-followup at FreeBSD.org, rich at enterprisesystems.net,
freebsd-hackers at freebsd.org
Subject: Re: misc/183495: utx.active not being updated correctly
Date: Thu, 14 Nov 2013 00:36:09 +0100
On Wed, Nov 13, 2013 at 09:58:32PM +0100, Ed Schouten wrote:
> [ +freebsd-hackers, to see whether this change would go in the right direction ]
> It seems that the regression described in misc/183495 is unrelated to
> utmpx alone. Unlike utmp, utmpx allows multiple entries per TTY. This
> causes the issue to become actually visible.
In some sense, having at most one entry per TTY is correct. Multiple
entries arise mostly by bugs that do not delete an entry on logout or by
(ab)use of /usr/bin/login's setuid bit. Also, it is not possible to
isolate two users properly if they are using the same TTY.
> telnetd uses login(1) to provide a login prompt, interactive shell,
> etc. Looking at the source code of login(1), it seems that it never
> attempts to call pam_cleanup() whenever the process terminates with
> SIGHUP, nor does it protect itself against SIGTERM properly. The
> following patch should fix this issue partially:
> Still, one issue that remains is that the parent process can still be
> killed using SIGKILL, thereby allowing you to circumvent
> pam_cleanup(). What would be the right approach to fix this? Changing
> the effective UID would solve this, but I don't feel really
> comfortable to modify these kind of pieces of software. It's easy to
> introduce security bugs.
At least on stable/9, the login [pam] process has all UIDs equal to 0
and cannot be killed by a normal user. However, it can receive SIGHUP if
the connection is closed. This should not lead to immediate termination,
so the SIGHUP part of the patch seems correct, although I have not
I am less sure about the SIGTERM part. Killing a login [pam] process may
be a "doctor it hurts if I do this" thing. If SIGTERM is not left at its
default action, perhaps it should kill process(es) associated with the
session somehow (most simply, by cleaning up PAM and audit and exiting,
which shuts down the session).
The only way to avoid problems with SIGKILL would be to put the PAM and
audit cleanup in a constantly running daemon such as init. I don't think
this is worth it. Root should not kill -9 login [pam] processes.
More information about the freebsd-bugs