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] linux ttyname and ttyname_r: return link if appropriate


Quoting Florian Weimer (fweimer@redhat.com):
> On 08/09/2016 11:39 PM, Serge E. Hallyn wrote:
> >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.
> 
> I'm still concerned that returning something which is not a stable
> reference to a fixed PTY could introduce security vulnerabilities
> because some applications may assume that if ttyname succeeds, the
> returned name is safe to chmod/chown

which (I think you know, but just to state it) it can be, but

> (even if the descriptor is
> closed beforehand).

Indeed, not, good point.

> Maybe this is small risk and is worth the change.  It seems rather
> unlikely that the process would close the descriptor and open a new
> one in its place before the file system change.

... not inconceivable though, but i would expect most cases of ttyname
plus chown would be using 0/1/2, not a newly opened fd.  This might be
worth a code search.

But, even if we decide that part is dangerous, the part where we do not
return /dev/pts/N when /proc/self/fd/M is from a different devpts mount
than the /dev/pts/N in caller's namespace is I think very important, and
should at least be separately applied.


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