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

[Laurent Bercot]

 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 "ralda at gmx.de" <ralda at gmx.de> -----

Delivered-To: ska-dietlibc at skarnet.org
X-Virus-Scanned: amavisd-new at osuosl.org
X-Original-To: busybox at lists.busybox.net
Delivered-To: busybox at osuosl.org
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: "ralda at gmx.de" <ralda at gmx.de>
To: busybox at busybox.net
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: busybox at busybox.net
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:busybox-request at busybox.net?subject=unsubscribe>
List-Archive: <http://lists.busybox.net/pipermail/busybox>
List-Post: <mailto:busybox at busybox.net>
List-Help: <mailto:busybox-request at busybox.net?subject=help>
List-Subscribe: <http://lists.busybox.net/mailman/listinfo/busybox>,
 <mailto:busybox-request at busybox.net?subject=subscribe>
Errors-To: busybox-bounces at busybox.net

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
busybox at busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

----- End forwarded message -----