This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/1] linux ttyname: return link if appropriate


Quoting Florian Weimer (fweimer@redhat.com):
> On 04/15/2016 06:46 PM, Serge Hallyn wrote:
> >Quoting Florian Weimer (fweimer@redhat.com):
> >>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.
> >>>http://pubs.opengroup.org/onlinepubs/009695399/functions/ttyname.html
> >>>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
> implications.

What security implications exactly?  Does ensuring that it is a
device on a devpts filesystem address them?

-serge


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]