lkml.org 
[lkml]   [2016]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Does anyone care about a race free ptsname?
Quoting Eric W. Biederman (ebiederm@xmission.com):
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > What this does is get rid of the horrible notion of having that
> >
> > struct inode *ptmx_inode
> >
> > be the interface between the pty code and devpts. By de-emphasizing the
> > ptmx inode, a lot of things actually get cleaner, and we will have a much
> > saner way forward.
>
> I will take a look in a minute. Before I do that I want to mention
> why I care about /dev/pts/ptmx.
>
> There is a posix function that is widely used called ptsname. It's
> function is to take a master file descriptor and returns the path to the
> slave.
>
> All we have in the kernel to support ptsname is an ioctl TIOCGPTN that
> returns the pty number in the appropriate instance of devpts.
>
> The only way we have today to query which instance of devpts the pty is
> on is through fstat and look st_dev to see if the file is on the correct
> filesystem. This works when /dev/pts/ptmx is used and fails when
> /dev/ptmx is used.
>
> Does anyone else care?
>
> If no one cares I will stop worrying about it and just get on with
> fixing the rest of this mess which there definitely seems to be the will
> to do.

There seem to be quite a few users of ptsname (as found by
codesearch.debian.net). I'm going to look through those results
a bit more tonight. One common idiom is

blah = ptsname(fd);
slavefd = open(blah, ...);

That's more easily solved with a new helper.

The scariest thing of course is any callers of ptsname which are setuid-root.

short answer: i'm going to do some research to try and answer "who cares".

-serge

\
 
 \ /
  Last update: 2016-04-19 23:01    [W:0.472 / U:0.964 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site