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 [email protected] for the whole thread. If you want to answer, please subscribe to the uClibc mailing-list. ;) -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
