Bug 643

Summary:	check_ttyname: FAIL /dev/pts/0 (sudo) vs. /dev/pts/18 (libc)
Product:	Sudo	Reporter:	Lars Wendler <polynomial-c>
Component:	Sudo	Assignee:	Todd C. Miller <Todd.Miller>
Status:	RESOLVED FIXED
Severity:	low	CC:	flameeyes
Priority:	low
Version:	1.8.10
Hardware:	PC
OS:	Linux
URL:	https://bugs.gentoo.org/487618
Attachments:	build.log

Description Lars Wendler 2014-04-19 06:11:56 MDT

This is not bug #630 as all sudo versions since introduction of this test in sudo-1.8.7 fail on Gentoo:

make[1]: Entering directory '/var/tmp/portage/app-admin/sudo-1.8.10_p2/work/sudo-1.8.10p2/src'
x86_64-pc-linux-gnu-gcc -c -I../include -I.. -I. -I. -I.. -D__STDC_WANT_LIB_EXT1__=1 -march=barcelona -mtune=barcelona -O2 -pipe -fvisibility=hidden -fPIE -fstack-protector-all -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -DLOCALEDIR=\"/usr/share/locale\"  ./regress/ttyname/check_ttyname.c
<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default]
./regress/ttyname/check_ttyname.c:1:0: note: this is the location of the previous definition
 /*
 ^
/bin/bash ../libtool --tag=disable-static --mode=link x86_64-pc-linux-gnu-gcc -o check_ttyname check_ttyname.o locale_stub.o ttyname.o -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wc,-fPIE -pie -Wc,-fstack-protector-all ../common/libsudo_util.la ../compat/libreplace.la
libtool: link: x86_64-pc-linux-gnu-gcc -o check_ttyname check_ttyname.o locale_stub.o ttyname.o -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -fPIE -pie -fstack-protector-all  ../common/.libs/libsudo_util.a ../compat/.libs/libreplace.a
check_ttyname: FAIL /dev/pts/0 (sudo) vs. /dev/pts/18 (libc)
Makefile:187: recipe for target 'check' failed
make[1]: *** [check] Error 1


Dunno if this is a bug in our toolchain or glibc. Feel free to close this bug if it's not a problem in sudo's test suite.

Comment 1 Lars Wendler 2014-04-19 06:15:03 MDT

Created attachment 404 [details]
build.log

Comment 2 Todd C. Miller 2014-05-05 14:43:31 MDT

I don't see that failure on other Linux systems so it's possible that this is an artifact of the build environment.  I'd still like to understand what is happening so I'll leave this bug open until I've figured that out.

Comment 3 Diego Elio Petteno' 2014-09-29 15:27:15 MDT

Good news, I ended up reproducing this and looking into it.

What happens is that stdin is closed, and you're using redirects for output (like Portage does), then your TTYs don't match. Sudo (correctly) gets tty0 for me, but then it can't find STDIN and the STDOUT/ERR are on a different tty.

One more problem:

        printf("%s: FAIL %s (sudo) vs. %s (libc)\n", getprogname(),
            tty_sudo ? tty_sudo : "none", tty_libc ? tty_sudo : "none");


It should be

        printf("%s: FAIL %s (sudo) vs. %s (libc)\n", getprogname(),
            tty_sudo ? tty_sudo : "none", tty_libc ? tty_libc : "none");

(see the difference in the second to latter token.)

HTH!

Comment 4 Todd C. Miller 2014-09-29 15:36:44 MDT

Closing since this is not a bug in the test.  I've fixed the error message as suggested, thanks!

Comment 5 Diego Elio Petteno' 2014-09-29 15:37:44 MDT

Well, it kinda is a problem with the test: it should not cause the whole tests to fail because it can't find STDIN.

Maybe SKIP?

Comment 6 Todd C. Miller 2014-09-29 15:50:50 MDT

The problem is not that stdin is closed but that stdout/stderr point to a different tty.  Just skipping the test when stdin is closed would prevent the test from working in my own build scripts.

Comment 7 Todd C. Miller 2014-10-08 02:36:26 MDT

It turns out my own build system no longer redirects stdin so I can get away with only checking ttyname(0) and skipping the test if that is not available.