As described in bug 55497, bug 56161, people have problems emerging software with NIS defined, getting an error about the system attempting to open /etc/default/nss I got this yet another time when attempting to emerge perl 5.8.4 Having gotten fed up, I found where this file was being accessed, in libnss_nis, and furthermore investigated the source code to see what it was doing. I determined that the following code was the cause: /var/tmp/portage/glibc-2.3.3.20040420/work/glibc-2.3.2/nis/nss-nis.c ------------------------------------------------------- static const char default_nss[] = "/etc/default/nss"; int _nis_check_default_nss (void) { FILE *fp = fopen (default_nss, "rc"); ------------------------------------------------------------------ Investigation showed that the undocumented 'c' modifier to the 'r(ead)' open type tells the system to use non-cancelable I/O calls. It is not clear to me why they saw the need for this, but that is rather beside the point. libsandbox should not believe that a modified read-open is somehow different from a normal read open. Investigation of /var/tmp/portage/glibc-2.3.3.20040420/work/glibc-2.3.2/libio/fileops.c suggests that the following modifiers are legal: +xbmc Combinations and different orders are legal as well (e.g. "rcx" "rxc"). Obviously '+' should be disallowed, but the others are acceptable. Bug 35821 suggests that 't' should be also allowed. It is not specifically accepted by the glibc code I examined, but please remember that 't' is the default so it is unnecessary. Yes, I do realize the 'b' is practically the default as well. I'll attempt to attach a patch ASAP. Reproducible: Always Steps to Reproduce: 1. Setup NIS 2. Emerge openoffice/perl/kdelibs/etc 3. Portage 2.0.50-r9 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.7-gentoo-r7) ================================================================= System uname: 2.6.7-gentoo-r7 i686 Pentium III (Coppermine) Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://gentoo.mirrored.ca/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X Xaw3d aalib acpi alsa apache2 apm arts audiofile avi berkdb caps cdr crypt cscope cups curl dga directfb doc emacs encode esd ethereal fdftk flac foomaticdb gd gdbm gif gmp gnome gphoto2 gpm gtk gtk2 hardened imagemagick imlib java joystick jpeg kde lcms ldap lesstif libg++ libwww mad mbox mikmod mmx motif mozilla mpeg mysql ncurses nls nocardbus nocd oggvorbis opengl oss pam pdflib perl plotutils png postgres ppds prelude python qt quicktime readline samba sdl slang snmp socks5 speex spell sse ssl svga tcltk tcpd tetex theora tiff truetype unicode usb videos wmf x86 xinerama xml xml2 xmms xosd xv zlib"
Created attachment 36097 [details, diff] libsandbox patch A proposed patch which specifically allows known valid modifiers which may appear in any order.
In the interest of full disclosure, I discovered that glibc stdio has even *MORE* undocumented usage of the mode string. They have this wierd ",css=" character set translation thingy. I did not fully track down what this does, but it appears to be some kind of internationalization/wide character set support. The patch I created does NOT handle this situation. It could be extended to do so, but that would require some more thought as to whether the css thingy could be exploited. Probably not, but you never know without looking. I have not seen any use of this, nor have I looked. I was just looking deeper into the function to track down another unrelated bug.
*** Bug 55497 has been marked as a duplicate of this bug. ***
*** Bug 60910 has been marked as a duplicate of this bug. ***
Bug has been fixed and released in stable portages on or before 2.0.51-r2
*** Bug 59128 has been marked as a duplicate of this bug. ***
