[397] in linux-security and linux-alert archive
Re: Problem with /dev/ttyp*
daemon@ATHENA.MIT.EDU (Malcolm Beattie)
Thu Sep 28 11:49:25 1995
From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
To: tytso@MIT.EDU (Theodore Ts'o)
Date: Fri, 22 Sep 1995 11:45:53 +0000 (BST)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <9509211930.AA24654@dcl.MIT.EDU> from "Theodore Ts'o" at Sep 21, 95 03:30:40 pm
Theodore Ts'o writes:
>
> From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
> Date: Thu, 21 Sep 1995 10:52:49 +0000 (BST)
>
> Surely if it's done the POSIX way then you don't need vhangup? The login
> process should become a session leader with setsid() and then acquire a
> pseudo-terminal as controlling terminal (see POSIX 7.1.1.3). Once it's
> done that, processes in any other session that try to read from/write to
> that terminal should get EOF on reads and EIO on writes (7.1.1.10).
>
> But POSIX doesn't specify that. Section 7.1.1.10 applies when a modem
> disconnect is detected by the terminal interface for a controlling
> terminal. 7.1.1.3 states that how a process can acquire a controlling
> terminal is "implementation defined" --- it MAY happen if the a process
> is a session leader and doesn't otherwise have a controlling terminal,
> but it's not guaranteed to.
I was perhaps a little ambiguous when I said "should get EOF on reads...".
What I meant was that the Linux kernel should behave that way (or be
made to behave that way) since it seems to be "good" behaviour to do so.
Before I go on, let me say I don't want to be dogmatic nor do I want
to give any egg-sucking lessons to aged relatives. I thought I
understood this stuff, but I may be wrong so treat me gently. I've only
got POSIX 1003.1 and not .1a so if there are any differences, I'd like
to know.
> In any case, nowhere in POSIX is it specified that access to the tty is
> revoked (as in a hangup) to other processes after it is acquired as a
> controlling terminal by a session loeader.
Although not required, it seems to be allowed. In the Rationale under
"Implementing Job Control Systems", it mentions the vhangup() and
SysV behaviour and and confirms that conforming POSIX application's
shouldn't muck around with a controlling terminal after logout.
Going back to 7.1.1.3:
When a controlling process terminates...Subsequent access to the
terminal by other processes in the earlier session may be denied,
with attempts to access the terminal treated as if modem
disconnect has been sensed.
The rationale also says
Note that, if an implementation chooses to deny access to a
controlling terminal after its controlling process exits, the
standard requires a certain type of behaviour (see 7.1.1.3).
The "as if modem disconnect has been sensed" behaviour is defined in
7.1.1.10 and is "reads return EOF, writes return -1 with EIO".
The rationale for 7.1.1.4 (sic) says that job control terminal access
control if only intended for controlling terminals and not other
access to terminals, but there's no equivalent rationale statement
for 7.1.1.3.
> If you think there is such a statement, please point it out to me; I've
> spent a lot of time studying the POSIX.1 (1990) specification while I
> was implementing POSIX job control for Linux, many years back, and I
> never ran into anything like that. It's possible that I missed it,
> though; so if you can point me at the POSIX chapter and verse where this
> is actually claimed, I'd appreciate it.
I know about you work on Linux, of course, which is why I'm wary about
making claims which apparently contradict your feelings. What I seem
to be claiming is that POSIX *allows* (rather than requires) an
implementation where the acquiring of a terminal as a controlling
terminal results in any other process being unable to read/write to
that terminal.
--Malcolm
--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services
