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