[PATCH 0/1] linux ttyname{_r}: return ENODEV not ENOENT

[PATCH 0/1] linux ttyname{_r}: return ENODEV not ENOENT

[Christian Brauner]

Hi guys,

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.

The patch in question is:

	commit 15e9a4f378c8607c2ae1aa465436af4321db0e23
	Author: Christian Brauner <christian.brauner@canonical.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@hallyn.com>
	    Signed-off-by: Christian Brauner <christian.brauner@ubuntu.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

[PATCH 1/1] linux ttyname{_r}: return ENODEV not ENOENT

[Christian Brauner]

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 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.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
---
 src/unistd/ttyname_r.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/unistd/ttyname_r.c b/src/unistd/ttyname_r.c
index a38ba4f2..33aa4ae1 100644
--- a/src/unistd/ttyname_r.c
+++ b/src/unistd/ttyname_r.c
@@ -23,7 +23,7 @@ int ttyname_r(int fd, char *name, size_t size)
 	if (stat(name, &st1) || fstat(fd, &st2))
 		return errno;
 	if (st1.st_dev != st2.st_dev || st1.st_ino != st2.st_ino)
-		return ENOENT;
+		return ENODEV;
 
 	return 0;
 }
-- 
2.11.0

Re: [PATCH 0/1] linux ttyname{_r}: return ENODEV not ENOENT

[Szabolcs Nagy]

* Christian Brauner <christian.brauner@ubuntu.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@canonical.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@hallyn.com>
> 	    Signed-off-by: Christian Brauner <christian.brauner@ubuntu.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

Re: [PATCH 0/1] linux ttyname{_r}: return ENODEV not ENOENT

[Rich Felker]

On Thu, Apr 06, 2017 at 06:18:32PM +0200, Szabolcs Nagy wrote:
> * Christian Brauner <christian.brauner@ubuntu.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).

I think this is a misreading of POSIX. POSIX doesn't allow returning a
standard error for a nonstandard purpose; returning EBADF or ENOTTY
here would clearly be non-conforming since the fd is valid and it's
not a non-tty fd (other functions like isatty will observe it being a
tty). ENOENT is conforming because implementations are allowed to
define their own errors. ENODEV is probably a better choice, though,
since it matches what glibc does.

> 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).

Yes, documenting it there would be a good improvement.

Rich

Re: [PATCH 0/1] linux ttyname{_r}: return ENODEV not ENOENT

[Christian Brauner]

On Thu, Apr 06, 2017 at 12:25:56PM -0400, Rich Felker wrote:
> On Thu, Apr 06, 2017 at 06:18:32PM +0200, Szabolcs Nagy wrote:
> > * Christian Brauner <christian.brauner@ubuntu.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).
> 
> I think this is a misreading of POSIX. POSIX doesn't allow returning a
> standard error for a nonstandard purpose; returning EBADF or ENOTTY
> here would clearly be non-conforming since the fd is valid and it's
> not a non-tty fd (other functions like isatty will observe it being a
> tty). ENOENT is conforming because implementations are allowed to
> define their own errors. ENODEV is probably a better choice, though,
> since it matches what glibc does.
> 
> > 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).
> 
> Yes, documenting it there would be a good improvement.

This has already been taken care of. :) Michael already merged the patch:
https://www.spinics.net/lists/linux-man/msg11444.html

Christian

Re: [PATCH 0/1] linux ttyname{_r}: return ENODEV not ENOENT

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2017-04-06 12:25:56 -0400]:

> On Thu, Apr 06, 2017 at 06:18:32PM +0200, Szabolcs Nagy wrote:
> > * Christian Brauner <christian.brauner@ubuntu.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).
> 
> I think this is a misreading of POSIX. POSIX doesn't allow returning a
> standard error for a nonstandard purpose; returning EBADF or ENOTTY
> here would clearly be non-conforming since the fd is valid and it's
> not a non-tty fd (other functions like isatty will observe it being a
> tty). ENOENT is conforming because implementations are allowed to
> define their own errors. ENODEV is probably a better choice, though,
> since it matches what glibc does.
> 

i didnt say the libc code should be changed, but
that applications should test for EBADF or ENOTTY
and if they find something else then assume something
else was the problem instead of checking something
undocumented and make assumptions based on that.

> > 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).
> 
> Yes, documenting it there would be a good improvement.
> 
> Rich

Re: [PATCH 0/1] linux ttyname{_r}: return ENODEV not ENOENT

[Rich Felker]

On Thu, Apr 06, 2017 at 06:36:47PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2017-04-06 12:25:56 -0400]:
> 
> > On Thu, Apr 06, 2017 at 06:18:32PM +0200, Szabolcs Nagy wrote:
> > > * Christian Brauner <christian.brauner@ubuntu.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).
> > 
> > I think this is a misreading of POSIX. POSIX doesn't allow returning a
> > standard error for a nonstandard purpose; returning EBADF or ENOTTY
> > here would clearly be non-conforming since the fd is valid and it's
> > not a non-tty fd (other functions like isatty will observe it being a
> > tty). ENOENT is conforming because implementations are allowed to
> > define their own errors. ENODEV is probably a better choice, though,
> > since it matches what glibc does.
> > 
> 
> i didnt say the libc code should be changed, but
> that applications should test for EBADF or ENOTTY
> and if they find something else then assume something
> else was the problem instead of checking something
> undocumented and make assumptions based on that.

Yes, I think that's correct. Or even just assume the error is always
something else. EBADF can never happen without a buggy program, and if
you already know the fd is a tty, ENOTTY can't happen either, so
there's probably no reason to handle these two.

Rich