Forwarded to the uClibc development mailing-list. Mail-Followup-To set. I think reading /proc/self/fd/1 (we want to test stdout, not stdin or stderr) is the right thing to do for the "tty" command, but I'm fairly sure you will break numerous other applications by dropping the read permissions on /dev/pts/.
-- Laurent ----- Forwarded message from "[email protected]" <[email protected]> ----- Delivered-To: [email protected] X-Virus-Scanned: amavisd-new at osuosl.org X-Original-To: [email protected] Delivered-To: [email protected] X-Virus-Scanned: amavisd-new at osuosl.org X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Authenticated: #19790935 X-Provags-ID: V01U2FsdGVkX19rqz82t5Fr2yoWfJRgzFU8eP/A0Nh+Mx7OmBWpwv REz3Kb0xmJye/T Date: Mon, 2 Apr 2012 08:04:39 +0200 From: "[email protected]" <[email protected]> To: [email protected] Subject: computer phenomena: output of tty applet X-Mailer: Sylpheed 3.1.3 (GTK+ 2.24.10; i686-pc-linux-gnu) X-Y-GMX-Trusted: 0 X-BeenThere: [email protected] X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion and development of BusyBox <busybox.busybox.net> List-Unsubscribe: <http://lists.busybox.net/mailman/options/busybox>, <mailto:[email protected]?subject=unsubscribe> List-Archive: <http://lists.busybox.net/pipermail/busybox> List-Post: <mailto:[email protected]> List-Help: <mailto:[email protected]?subject=help> List-Subscribe: <http://lists.busybox.net/mailman/listinfo/busybox>, <mailto:[email protected]?subject=subscribe> Errors-To: [email protected] Hi! I just stumbled about an interesting phenomena: I tried some new/modified scripts via remote ssh access. As part of the script debugging I put in some diagnostic messages. One of those the output of the "tty" command. All previous tests in other environments gave me an expected "/dev/pts/N" but suddenly I got "not a tty". My first assumption was that dropbear did not allocate a pty but after several tries the GNU tty still printed "/dev/pts/N" where Busybox tty responded "not a tty". So I tried to look at the code of GNU tty and Busybox tty and couldn't find a significant difference. So where had the required tty name gone? A comparison of strace output of both GNU and Busybox tty call revealed a big difference. The Busybox version has been compiled with uClibc. And that one tries to search the /dev directory for an entry matching the major/minor device number where the GNU version just read the symlink at /proc/self/fd/2. 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. So it is not a Busybox bug, but it took me some hours of searching for the problem. I don't think that it is a good decision to search the /dev directory for a matching entry where that information is available from a simple readlink(/proc/self/fd/0). So if anybody is able to forward this to the uClibc developers it would be very nice. -- Harald _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox ----- End forwarded message ----- _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
