This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 1/1] linux ttyname: return link if appropriate
- From: Serge Hallyn <serge dot hallyn at ubuntu dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org, Serge Hallyn <serge dot hallyn at ubuntu dot com>
- Date: Fri, 15 Apr 2016 17:42:45 +0000
- Subject: Re: [PATCH 1/1] linux ttyname: return link if appropriate
- Authentication-results: sourceware.org; auth=none
- References: <20160415152929 dot GA7932 at ubuntumail> <5711165D dot 5040902 at redhat dot com> <20160415164652 dot GE8450 at ubuntumail> <57111F9C dot 8030902 at redhat dot com>
Quoting Florian Weimer (email@example.com):
> On 04/15/2016 06:46 PM, Serge Hallyn wrote:
> >Quoting Florian Weimer (firstname.lastname@example.org):
> >>On 04/15/2016 05:29 PM, Serge Hallyn wrote:
> >>>The current ttyname does the wrong thing in two cases:
> >>>1. If the passed-in link (say /proc/self/fd/0) points to a
> >>>device, say /dev/pts/2, in a parent mount namespace, 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.
> >>Is this the first change?
> >Right, it ensures that the filesystem of the two files is
> >the same.
> >>>2. If the passed-in link (say /proc/self/fd/0) points to
> >>>a device, say /dev/pts/2, in a parent mount namespace, and
> >>>/dev/pts/2 does not exist in the current namespace, it
> >>>returns success but an empty name. As far as I can tell,
> >>>there is no reason for it to not return /proc/self/fd/0.
> >>>does not say anything about not returning a link.
> >>Is it safe to drop the verification that ttyname ordinarily would do?
> >Which verification do you mean exactly?
> That the file descriptor actually belongs to a PTY device listed
> under /dev/pts.
Oh, yeah. I think that adding a chck that this is a pts (using st_rdev)
before returning "/proc/self/fd/N" (in my newly added block) would be good.
> >>ttyname_r will need a similar change.
> >Oh, yeah, it will.
> Please also fix the stylistic issues (GNU style requires a space in
> function calls, braces on their own lines etc.).
Oh, yes I can update those.
> But I don't think we can make the change, considering the security
What security implications exactly? Does ensuring that it is a
device on a devpts filesystem address them?