If you have a user in the group portage, then the user can't see the contents of the work directory. Also if the user executes `ebuild someebuild-version.ebuild unpack` then the contents will belong to the user and probably the group users. Reproducible: Always Steps to Reproduce: 1. ebuild somepackage-version.ebuild unpack 2. su <some other user in the portage group> 3. cd /var/tmp/portage/somepackage/work Actual Results: access denied Expected Results: all users in group portage ought to be allowed into the work directory Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r1, 2.6.12-gentoo-r6 i686) ================================================================= System uname: 2.6.12-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.6.13 distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.esoft.dk/gentoo http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://ftp.snt.utwente.nl/pub/os/linux/gentoo" LINGUAS="da" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/esoft-portage" SYNC="rsync://mirror.esoft.dk/gentoo-portage" USE="x86 X alsa apache2 apm arts avi bash-completion bcmath berkdb bitmap-fonts bzlib calendar crypt ctype cups curl dba eds emboss encode exif fam firefox flac flash foomaticdb fortran ftp gd gdbm gif gpm graphviz gstreamer gtk2 iconv imagemagick imap imlib ipv6 jabber java jbig jpeg junit kde lcms libg++ libwww mad mhash mikmod mime ming mmx motif mozilla mozsvg mp3 mpeg msn mysql ncurses nls odbc ogg oggvorbis opengl oss pam pcntl pcre pdflib perl php png posix postgres python qt quicktime readline samba sdl session slang snmp soap sockets spell spl sse sse2 ssl svga tcpd tidy tiff truetype truetype-fonts type1-fonts unicode usb vorbis wmf xine xml xml2 xmms xsl xv zlib linguas_da userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS
Why should all users (in the portage group) be allowed access?
No reasoning provided.
Sorry about my late reply. Maybe all portage users shouldn't be able to see the work directory. The other dirs in /var/tmp/portage/bioperl-1.4/ are accessible to the portage group. So I ask what is so special about the work directory? Also the other thing I noted in my first description. I am allowed to do this as a user in the portage group: olberd@ip10 /usr/portage/sci-biology/bioperl $ ebuild bioperl-1.4.ebuild unpack ... >>> Unpacking bioperl-1.4.tar.bz2 to /var/tmp/portage/bioperl-1.4/work >>> Source unpacked. But as you can see: olberd@ip10 /usr/portage/sci-biology/bioperl $ ls -la /var/tmp/portage/bioperl-1.4/ totalt 0 drwxr-xr-x 4 olberd users 128 6 okt 10:43 . drwxrwxr-x 502 portage portage 18K 6 okt 10:43 .. drwxr-xr-x 2 olberd users 112 6 okt 10:43 temp -rw-r--r-- 1 olberd users 0 6 okt 10:43 .unpacked drwx------ 3 olberd users 80 6 okt 10:43 work olberd@ip10 /usr/portage/sci-biology/bioperl $ Everything in this dir is now owned by the user and accessible to the group users. Shouldn't the /var/tmp/portage content have consistent access rights whether executed with root privileges or as a user in portage group? What are the arguments behind the different access rights in the /var/tmp/portage dir?
*** This bug has been marked as a duplicate of 8688 ***
