[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/53229 (textproc/py-expat does not build w/o terminal session)
The following reply was made to PR pkg/53229; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: pkg/53229 (textproc/py-expat does not build w/o terminal session)
Date: Wed, 10 Apr 2019 03:24:14 +0700
Date: Tue, 9 Apr 2019 17:10:55 +0000 (UTC)
| Problem analyzed, patch fixes the problem but not committed
| because it would be nice if anyone more familiar with dup, fstat
| semantics and standards can confirm that's actually ok!
The simple answer to that is that it is obviously OK to use any
technique you like (which works) to test if an fd is valid or not.
So, the patch seems to be fine (switching NetBSD to use fstat() rather
On the broader question of whether the way NetBSD treats revoked terminals
is POSIX compatible or not, from a quick glance at things, I'd say not.
(However it is how BSD has done it for a long time, and I will ask on the
austin group list for opinions from others).
But POSIX XBD (basic definitions) section 11.1.3 ("The Controlling Terminal")
When a controlling process terminates, the controlling terminal
is dissociated from the current session, allowing it to be
acquired by a new session leader.
That's what happens when the login shell exits.
Subsequent access to the terminal by other processes in the earlier
session may be denied, with attempts to access the terminal treated
as if a modem disconnect had been sensed.
And this is what we are more or less achieving by the revoke, or
it is with the same objective.
And then, in XBD 11.1.10 ("Modem Diosconnect")
If a modem disconnect is detected by the terminal interface for
a controlling terminal, and if CLOCAL is not set in the c_cflag
field for the terminal (see Section 11.2.4, on page 209), the
SIGHUP signal shall be sent to the controlling process for which
the terminal is the controlling terminal. Unless other arrangements
have been made, this shall cause the controlling process to
terminate (see exit( )).
That part is it is not really relevant, the background processing setup
includes ignoring SIGHUP. So here the state of CLOCAL is irrelevant
(which is what would be wanted anyway.)
Any subsequent read from the terminal device shall return the
value of zero, indicating end-of-file; see read( ). Thus, processes
that read a terminal file and test for end-of-file can terminate
appropriately after a disconnect. If the EIO condition as specified
in read( ) also exists, it is unspecified whether on EOF condition
or [EIO] is returned. Any subsequent write( ) to the terminal device
shall return -1, with errno set to [EIO], until the device is closed.
But that suggests that returning EBADF for a revoked terminal is not the
POSIX specified approach, the fd should remain valid, and simply be unable
to perform any I/O. (Since ioctl() is not a POSIX interface, what happens
with attempts to do that is clearly not specified. However some operations
that are typically implemented using ioctl() are specified, and those make
no mention of returning an error for a terminal after a "modem disconnect".)
From that I would suspect that both dup() and fstat() should continue to
work on a revoked terminal (no errors) and that a later I/O request should
fail (what this would do to python I have no idea, as by changing the
dup() to fstat() for NetBSD suggests that the error is wanted, which if I
am correct about posix, should not be generated from either. Of course,
this might only matter if some later call generates EBADF, and EIO or EOF
might be treated differently.
And as an aside, I don't know about MacOS, but on NetBSD, fcntl(F_GETFL)
would be a cheaper (cheaper even than dup, as no close() is needed) way to
test whether the fd is valid or not. When EBADF is to be returned, all
of them are equally cheap, but when there is no error, fstat() copies out
a bunch of unwanted data, dup() returns an fd that needs to be closed, and
fcntl(F_FETFL) simply returns an int which is easily ignored.
I will append more to this PR if any meaningful response comes from the
Main Index |
Thread Index |