From: Albert Cahalan <albert@users.sf.net>
To: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Cc: aebr@win.tue.nl
Subject: pty master close and SIGHUP
Date: 16 Jul 2004 10:31:22 -0400 [thread overview]
Message-ID: <1089988282.1231.378.camel@cube> (raw)
Something is wrong with the kernel, or maybe with this:
http://www.win.tue.nl/~aeb/linux/lk/lk-12.html#ss10.3.4
As I recall, the SIGHUP is sent by the kernel itself when
the master is closed or the session leader dies. I think
there is a credentials problem in the kernel now, with the
signal being sent as if the master-side process or session
leader had sent it. I do indeed find a check_kill_permission()
call that ought not be made AFAIK. The TTY code makes an
effort to force the SIGHUP, but this gets ignored. Maybe
some "cleanup" tried to share common code?
Here's an example. First, I start an xterm. Then in that
xterm, I use "su -" to become root and I start "top".
The processes now look like this:
$ ps -p 7204 -t pts/25 -o euid,ruid,tty,sess,pgrp,ppid,pid,tpgid,stat,pcpu,comm
EUID RUID TT SESS PGRP PPID PID TPGID STAT %CPU COMMAND
1000 1000 ? 7196 7204 1 7204 -1 S 0.0 xterm
1000 1000 pts/25 7205 7205 7204 7205 7218 Ss 0.0 bash
0 0 pts/25 7205 7213 7205 7213 7218 S 0.0 bash
0 0 pts/25 7205 7218 7213 7218 7218 S+ 1.3 top
As you can see, the session leader is bash #7204 and top
is the sole process in the foreground process group.
Now I close the xterm. It dies. The session leader also dies.
This should then cause all processes in the foreground process
group to get SIGHUP. If top gets SIGHUP, it shuts down. This
all works great normally, but see what happens when top is
running as root:
$ ps -p 7204 -s 7205 -o euid,ruid,tty,sess,pgrp,ppid,pid,tpgid,stat,pcpu,comm
EUID RUID TT SESS PGRP PPID PID TPGID STAT %CPU COMMAND
0 0 ? 7205 7213 1 7213 -1 S 0.0 bash
0 0 ? 7205 7218 7213 7218 -1 R 51.4 top
The SIGHUP is never delivered.
Now I know it isn't really clean to let top spin calling select()
when the tty goes away, but SIGHUP should take care of that.
Where is my SIGHUP?
I recall the rules being even looser traditionally, pretty much
allowing you to send signals (at least some of them) to anything
on your tty or in your session. Was there a SysV/BSD/POSIX
disagreement over this?
reply other threads:[~2004-07-16 16:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1089988282.1231.378.camel@cube \
--to=albert@users.sf.net \
--cc=aebr@win.tue.nl \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox