[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Apr 2017 18:18:32 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Christian Brauner <christian.brauner@...ntu.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH 0/1] linux ttyname{_r}: return ENODEV not ENOENT
* Christian Brauner <christian.brauner@...ntu.com> [2017-04-06 00:32:17 +0200]:
> After a long struggle we've recently upstreamed a patch to glibc that handles
> the case where a pts device might not be available even though the corresponding
> file desciptor refers to a terminal. The classic example is obviously mount
> namespaces in Linux although this can also be caused by overmounting or other
> scenarios. While musl correctly detects whether the pts device a given file
> descriptor refers to can be retrieved it returns ENOENT. We've recently
> upstreamed a patch to glibc which uses ENODEV. This has been after a discussion
> about what errno would be most in line with POSIX. Additionally we fixed a bunch
> of programs to handle the ENODEV case. It would be good if musl would also set
> ENODEV instead of ENOENT to enable programs to have uniform handle on this case
> and to minimize the differences between the libcs.
>
why do applications care about the errno value?
all they should care about is that there is no
known tty name if the call failed.
if they really want to look at the errno then
test for ENOTTY or EBADF (which are specified
by posix) not for ENODEV (which is not documented
anywhere and thus is a libc internal detail that
may change any time in the future).
aligning musl with glibc makes sense (except of
course that there might be existing code relying
on the musl behaviour), but the right way to do
that is to document the linux specific errno in
the linux man pages project (then applications
can justifiably rely on it).
> The patch in question is:
>
> commit 15e9a4f378c8607c2ae1aa465436af4321db0e23
> Author: Christian Brauner <christian.brauner@...onical.com>
> Date: Fri Jan 27 15:59:59 2017 +0100
>
> linux ttyname and ttyname_r: do not return wrong results
>
> If a link (say /proc/self/fd/0) pointing to a device, say /dev/pts/2, in a
> parent mount namespace is passed to ttyname, and a /dev/pts/2 exists (in a
> different devpts) in the current namespace, then it returns /dev/pts/2.
> But /dev/pts/2 is NOT the current tty, it is a different file and device.
>
> Detect this case and return ENODEV. Userspace can choose to take this as a hint
> that the fd points to a tty device but to act on the fd rather than the link.
>
> Signed-off-by: Serge Hallyn <serge@...lyn.com>
> Signed-off-by: Christian Brauner <christian.brauner@...ntu.com>
>
> If possible, please Cc me on this since I'm not subscribed to the mailing list
> (yet).
>
> Thanks!
> Christian
>
> Christian Brauner (1):
> linux ttyname{_r}: return ENODEV not ENOENT
>
> src/unistd/ttyname_r.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --
> 2.11.0
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
