[ralda at gmx.de: computer phenomena: output of tty applet]

[walter harms]

It would be helpful if someone could write that down,
so it can be added to "know known problems" or so.

re,
 wh


Am 02.04.2012 17:08, schrieb Laurent Bercot:
>  Hi Harald,
> 
> 
>> As far as I know is tty specified to test the stdin so fd 0 is the
>> right one (fd 2 was a typo of mine, sorry). Currently Busybox and GNU
>> tty test stdin and glibc does readlink /proc/self/fd/0 (from strace
>> output).
> 
>  Oh, right, my bad. /proc/self/fd/0, then: glibc is doing the right
> thing. (For once.)
>  However, note that /proc/self/fd is Linux-only, whereas /dev/pts
> is Unix98, so supposedly more portable. I agree that the uClibc
> should optimize the Linux case into readlink'ing /proc/self/fd/0,
> though.
> 
> 
>>> but I'm fairly sure you will break numerous other applications
>>> by dropping the read permissions on /dev/pts/.
>>
>> Currently none!
> 
>  Fine - but Rich Felker writes (on the uClibc mailing-list):
> 
> << Please note that this does not provide *ANY* privacy/security
> << advantage. If you want a list of open ptys and owners, you can just
> << try stat() on /dev/pts/%d for each integer and get the same
> << information you would have gotten from reading the directory. To make
> << this secure, the kernel would need to be changed to generate random
> << tokens of at least 64bit for each pty...
> 
>  And he's right: no use preventing a directory from being read if the
> names of the files it contains are so easily predictable.
> 
>  I'm not going to play postman between you and uclibc at uclibc.org for
> the whole thread. If you want to answer, please subscribe to the uClibc
> mailing-list. ;)
>