Hi Rich! > > So the reason why Busybox neglected to > > respond with the pty name was, I dropped the read permission of > > the /dev/pts and gave only execute permission to that directory. > > Please note that this does not provide *ANY* privacy/security > advantage.
I know. It is just the way I like to have things done: Remove all rights and give only what is absolutely required. Helps to avoid some pitfalls (e.g. remember to have someones eyes not on things they shall not have) ... or just call it a kind of novice protection. To state it clear: I did not complain about the permission problem. I just wonder about what was happening and tried to explain how I stumbled about the problem. My request was about the silly thing to scan through the complete list of devices to find the right pty entry when that information can easily be read from the link in /proc/self/fd/0. This scan takes a relatively long time and needs code for the loop. Ok, I know, reading the link needs access to proc filesystem but which Linux system do not enable that access in it's early boot stage? And if proc is really not available (in the early boot process) the call to ttyname may just fail with an error which let tty complain with "not a tty". At that time you usually know your tty (/dev/console) and the test "[ -t 0 ]" still works right. IMHO a good case how to save time and space in uClibc. May be with a configurable option if readlink is used or the scan loop, with a Linux default of readlink. -- Harald _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
