Since portage-2.1_pre10 (IIRC), When root has umask 0077 set, portage handles permissions the wrong way in some places: 1) in /var/db/pkg, the directories of have permissions 700 (rwx------) set, the other files in it have 600 2) when emerging a binary package made with quickpkg (after uninstalling the previously intalled package), some permissions are messed up. Example: wine /usr/bin/wine* have 755 (correct) /usr/lib/wine/* have 755 or 644 (correct), but /usr/lib/wine itself has 700 The same goes for /usr/include/wine, the directory itself and its subdirectories have 700 set, other files in it have 644. 3) Sometimes, after having been using portage quite a bit, umask gets set to 0022; this rarely happens and I'm not sure if this is done by portage or something else, but I haven't seen this before 2.1_pre10 and I don't know what else could cause this. Hopefully, I made myself clear and this isn't a duplicate - I simply couldn't find an issue like this in all the portage bugreports. Oh, has been happening since before I have been using LDFLAGS="-Wl,--as-needed". Portage 2.1_rc1-r1 (selinux/2005.1/x86/hardened, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-hardened-r6 i686) ================================================================= System uname: 2.6.16-hardened-r6 i686 Intel(R) Pentium(R) 4 CPU 1.60GHz Gentoo Base System version 1.6.15 dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.92 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe -march=pentium4 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -march=pentium4 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--alphabetical" FEATURES="autoconfig collision-protect distlocks loadpolicy metadata-transfer parallel-fetch sandbox selinux sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/" LANG="en_US.UTF-8" LDFLAGS="-Wl,--as-needed" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from /etc/portage/rsync_excludes" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 X a52 aac alsa bzip2 caps cjk crypt cups curl dts dvd dvdread ffmpeg flac gif glut gtk hardened idn ipv6 jpeg mad matroska mikmod mmap mmx mp3 ncurses nptl offensive ogg opengl pam pic png readline sdl selinux sndfile sse sse2 ssl theora threads tiff truetype unicode vorbis win32codecs xinerama xv xvid zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_en userland_GNU" Unset: ASFLAGS, CTARGET, INSTALL_MASK, LC_ALL
Prior to 2.1_pre10, caller's umask was completely ignored because portage.py would always set the global umask to 022 (I removed that in svn r3228). I'll fix it so that portage sets the umask to 022 for creation of the /var/db/pkg entries. The above will solve (1), but I'm not sure about (2) and (3). (2) shouldn't be an issue because portage already sets the umask to 0 during the merge phase (in the dblink.treewalk() method). I'm not sure that I understand (3) correctly. Are you saying that emerge altered the umask of the calling process? That's impossible.
I've fixed it in svn r3354 so that the caller's umask doesn't matter (once again).
(In reply to comment #1) > The above will solve (1), Thanks! > but I'm not sure about (2) and (3). (2) shouldn't be > an issue because portage already sets the umask to 0 during the merge phase (in > the dblink.treewalk() method). This is reproducible every time I try this, with different packages created by quickpkg. The directories are being created 700, the rest has correct permissions. With umask 022, the directories get the correct permissions (755), too. When emerging from source, all permissions are correct, so only prebuilt packages are affected. > I'm not sure that I understand (3) correctly. > Are you saying that emerge altered the umask of the calling process? That's > impossible. I'm with you on that. I have only seen this a few times and I am not sure if I had been using the same terminal or a newly opened one. I was just surprised to see entries in /var/db/pkg with the permissions I wanted, checked the umask and it was set to 022 instead of 077. Shouldn't be a portage issue, so, well, just forget about that. :-) But I'd really like to know where this came from.
This has been released in 2.1_rc2-r2.
