Hi, I was running into strange sandbox violations with separate packages (coreutils, vim, and others). As it turned out, because my fs is mounted with the bsdgroups option, these packages don't install symlinks as root:root. ebuild.sh looks for files installed as portage group/user and changes it to root, then restores the original permissions in case the chown/chgrp changed it. However, restoring the original permissions fails because (on this system, apparently it's system-dependent) it tries to chmod the target of the symlink, not the symlink itself. With this patch, it doesn't try to save and restore permissions of symlinks, and the packages emerge without a problem. Symlinks shouldn't need a chmod, so I can't imagine why it'd break anything either. --- bin.orig/ebuild.sh +++ bin/ebuild.sh @@ -1075,8 +1075,10 @@ local count=0 find "${D}/" -user portage | while read file; do count=$(( $count + 1 )) + [[ ! -L ${file} ]] && s=$(stat_perms $file) chown root "$file" + [[ ! -L ${file} ]] && chmod "$s" "$file" done if (( $count > 0 )); then @@ -1086,12 +1088,14 @@ count=0 find "${D}/" -group portage | while read file; do count=$(( $count + 1 )) + [[ ! -L ${file} ]] && s=$(stat_perms "$file") if [ "$USERLAND" == "BSD" ] || [ "$USERLAND" == "Darwin" ];then chgrp wheel "$file" else chgrp root "$file" fi + [[ ! -L ${file} ]] && chmod "$s" "$file" done if (( $count > 0 )); then
ive seen `chown` on a symlink cause sandbox errors ... the newer sandbox checks for the target of the symlink since running `chown` on a symlink will change the target what i'm trying to say is that ive seen this in 'normal' Linux systems as well
emerge --info as requested: Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-4.0.0, glibc-2.3.5-r0, 2.6.12-rc4 i686) ================================================================= System uname: 2.6.12-rc4 i686 AMD Duron(tm) Processor Gentoo Base System version 1.6.12 ccache version 2.4 [enabled] dev-lang/python: 2.4.1 sys-apps/sandbox: 1.2.8 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.5 sys-devel/binutils: 2.16.90.0.3 sys-devel/libtool: 1.5.18 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -O2 -pipe -fomit-frame-pointer -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon-tbird -O2 -pipe -fomit-frame-pointer -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fvisibility-inlines-hidden" DISTDIR="/var/dist" FEATURES="autoconfig ccache collision-protect cvs distlocks noauto notitles sandbox sfperms strict" GENTOO_MIRRORS=" http://ftp.easynet.nl/mirror/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo " LANG="en_GB.UTF-8" LINGUAS="en en_GB ja nl" MAKEOPTS="-j1" PKGDIR="/var/pkg" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cvs/gentoo-x86" PORTDIR_OVERLAY="/etc/portage/cross /etc/portage/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X aac accessibility acl alsa audiofile berkdb bidi bitmap-fonts cdparanoia cjk crypt dvd dvdread encode erandom fbcon ffmpeg gdbm gif gnutls gpm gtk gtk2 hal imlib imlib2 ipv6 ithreads jpeg libg++ lua lynxkeymap mad mikmod mmx mmxext motif mp3 mpeg ncurses nls nocxx nodrm nopie noplugin nossp nptl ogg oggvorbis opengl oss pcre perl pic png postgres qt quicktime readline rtc slang spell ssl svg tcpd tetex threads tiff truetype truetype-fonts type1-fonts unicode userlocales vim-pager vorbis win32codecs wmf xface xgetdefault xml2 xv xvid zlib linguas_en linguas_en_GB linguas_ja linguas_nl userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS > ive seen `chown` on a symlink cause sandbox errors ... the newer sandbox checks > for the target of the symlink since running `chown` on a symlink will change the > target Oh great, in that case that patch won't be good enough... However, symlinks installed as portage:portage should still have it changed to root. If chown fails, any ideas on how to do it?
Agreed on the symlinks. The following should be enough, no? Either way, I'll be changing the wheel/root bit below to use "0" instead as well. @@ -1078,6 +1076,7 @@ local file s local count=0 find "${D}/" -user portage | while read file; do + [[ -L "${file}" ]] && continue; count=$(( $count + 1 )) s=$(stat_perms "$file") if [ -z "${s}" ]; then @@ -1093,17 +1092,14 @@ count=0 find "${D}/" -group portage | while read file; do + [[ -L "${file}" ]] && continue; count=$(( $count + 1 )) s=$(stat_perms "$file") if [ -z "${s}" ]; then echo "failed stat_perm'ing '$file' . User intervention during install isn't wise..." continue fi - if [ "$USERLAND" == "BSD" ] || [ "$USERLAND" == "Darwin" ];then - chgrp wheel "$file" - else - chgrp root "$file" - fi + chgrp 0 "${file}" chmod "$s" "$file" done if (( $count > 0 )); then
That should mostly work too, but that will keep the symlinks as owned by the portage group/user, because it also skips the chown/chgrp (which does work here), not just the chmod. (Also, if you do that, you could use find ... ! -type l instead :))
What's the point of the stat_perms/chmod? Can chown/chgrp changed the permission mode of a file?
Also, I realized that excluding symlinks altogether will probably break OSX. I seem to recall hearing that the permissions of symlinks do matter in mac-land.
> What's the point of the stat_perms/chmod? Can chown/chgrp changed the > permission mode of a file? Yeah, it can clear setuid/setgid flags. (However, if something's installed setuid/setgid, the makefile/ebuild really should make sure the user/group is set correctly anyway, so that might not be a big problem.)
Does chmod work on the symlink or the destination on OSX?
> ------- Additional Comment #8 From Jason Stubbs 2005-06-01 07:38 PDT ------- > Does chmod work on the symlink or the destination on OSX? Destination.
So the patch in the original is the best we've got so far then.. This concerns me in the chown man page though: -h, --no-dereference Act on symbolic links themselves instead of what they point to. Only available if the lchown system call is provided. So what we really need is two different code paths based on whether it's a symbolic link or not? Is this option (short or long) available on BSD? What about MacOS? What about the MacOS that doesn't have lchown?
Okay, chgrp changes the ownership of the symlink by default here. Seeing sandbox doesn't work on the BSDs yet, I'll leave the rest as is and go with the first patch.
*** Bug 96568 has been marked as a duplicate of this bug. ***
Fixed on or before 2.0.51.22-r1
Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened.
Earlier this morning, I submitted bug 99237 ("Sandbox violation emerging sys-apps/shadow-4.0.7-r3 (upgrade from 4.0.5-r3)"). Now, I've discovered that the problem described there seems to be happening with other ebuilds, including php-cgi (which is what made me realize that sys/apps- shadow isn't an isolated incident.) The problem I was seeing with those two ebuilds is the same one documented here. In comment #14, Jason said this was fixed "on or before 2.0.51.22-r1". These problems only began (for me) *after* upgrading to 2.0.51.22-r1 from 2.0.51.19. According to Harald's emerge --info output, he also found this problem while using 2.0.51.22-r1. (I am, also, like him, using bsdgroups.) This bug should definitely be reopened, and my bug 99237 should probably be marked as a dup of this. (Bug 95292 ("nullmailer-1.00 ebuild gets sandbox violation doing chmod on mailq symlink") looks related too.) IMO, the severity of this bug should also be increased, as many ebuilds are now failing to emerge with the stable version of portage.
*** Bug 99237 has been marked as a duplicate of this bug. ***
Jason, please have a look .. seems this is not fixed yet.
I can confirm this problem is not fixed. I originally reported sandbox violations in bug #96568 and later marked it as a dup of this one. As documented in bug #96568, I downgraded to a stable version of portage and the problem went away. Now that portage 2.0.51.22-r1 has been marked stable the problem has resurfaced. I did a 'emerge -Dub system' on the 16th and the sandbox violations started to occur again shortly after portage 2.0.51.22-r1 was installed. This time I got a sandbox violation on sys-apps/shadow-4.0.7-r3. Here is the contents of '/tmp/sandbox-sys-apps_-_shadow-4.0.7-r3-23322.log' for reference: chmod: /var/tmp/portage/shadow-4.0.7-r3/image/usr/bin/passwd (symlink to /bin/passwd) ----- The interesting thing is I have a server with the same FEATURES enabled and after the upgrade to portage 2.0.51.22-r1 none of the packages afterward produced sandbox violations---not even sys-apps/shadow-4.0.7-r3. I have two other test boxes but have not upgraded on then yet. Here is the output of 'emerge info' for my workstation, which is having sandbox violations: # emerge info Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r0, 2.6.11-gentoo-r11 i686) ================================================================= System uname: 2.6.11-gentoo-r11 i686 Unknown CPU Type Gentoo Base System version 1.6.12 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.10 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.5 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="-march=athlon-xp -m3dnow -mmmx -msse -O2 -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/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /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/X11/*/app-defaults /etc/X11/app-defaults /etc/X11/gdm /etc/X11/rstart/rstartd.real /etc/X11/serverconfig /etc/X11/starthere /etc/X11/sysconfig /etc/X11/xdm/chooser /etc/X11/xorg.conf.example /etc/gconf /etc/gnome-vfs-2.0/modules /etc/hotplug /etc/init.d /etc/openldap/schema /etc/sound/event /etc/terminfo /usr/X11R6/lib/X11/xkb /etc/env.d" CXXFLAGS="-march=athlon-xp -m3dnow -mmmx -msse -O2 -fomit-frame-pointer" DISTDIR="/usr/local/share/data/pub/linux/gentoo/distfiles" FEATURES="autoconfig buildpkg ccache distcc distlocks sandbox sfperms strict userpriv" GENTOO_MIRRORS="http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US" LINGUAS="en" MAKEOPTS="-j4" PKGDIR="/usr/local/share/data/pub/linux/gentoo/packages/athlon-xp" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/share/data/pub/linux/gentoo/portage /usr/local/share/data/pub/linux/gentoo/portage-bmg" SYNC="rsync://charge.electrostatic.org/gentoo-portage" USE="x86 3dnow 3dnowext X Xaw3d acl alsa apm arts audiofile avi berkdb bitmap-fonts bonobo cdparanoia cdr crypt cups curl dga divx4linux dv dvd dvdr dvdread eds emboss encode esd evms2 evo fam flac foomaticdb gd gdbm gif gnome gnome2 gpm gstreamer gtk gtk2 gtkhtml guile hal ieee1394 imagemagick imlib ipv6 java jpeg kde kdeenablefinal ldap libg++ libwww live mad mmx mmx2 mmxext motif mozilla mp3 mpeg mysql nas ncurses network nvidia offensive ofx ogg oggvorbis opengl pam pdflib perl png python qt quicktime quotes readline samba scanner sdl spell sse ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts usb userlocales v4l v4l2 vorbis xine xml xml2 xmms xscreensaver xv xvid xvmc zlib linguas_en userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS ----- Here is the merge history for the 16th on my workstation: # genlop -ln | grep 'Sat Jul 16' | sed -e 's/^[[:space:]]\+//g' Sat Jul 16 18:54:55 2005 >>> sys-devel/gcc-config-1.3.11-r4 Sat Jul 16 18:57:31 2005 >>> app-shells/bash-3.0-r12 Sat Jul 16 19:00:16 2005 >>> sys-kernel/linux-headers-2.6.11-r2 Sat Jul 16 20:05:56 2005 >>> sys-libs/glibc-2.3.5 Sat Jul 16 20:06:49 2005 >>> sys-apps/pam-login-3.17 Sat Jul 16 20:07:54 2005 >>> sys-libs/com_err-1.38 Sat Jul 16 20:09:03 2005 >>> sys-libs/ss-1.38 Sat Jul 16 20:10:56 2005 >>> sys-devel/libtool-1.5.18-r1 Sat Jul 16 21:22:10 2005 >>> x11-base/xorg-x11-6.8.2-r2 Sat Jul 16 21:22:49 2005 >>> app-arch/rpm2targz-9.0-r3 Sat Jul 16 21:23:42 2005 >>> sys-apps/sandbox-1.2.10 Sat Jul 16 21:24:31 2005 >>> sys-apps/portage-2.0.51.22-r1 *** Sat Jul 16 21:28:45 2005 >>> app-arch/bzip2-1.0.3-r4 Sat Jul 16 21:29:21 2005 >>> app-arch/gzip-1.3.5-r8 Sat Jul 16 21:29:40 2005 >>> sys-devel/autoconf-wrapper-3-r1 Sat Jul 16 21:30:25 2005 >>> sys-libs/cracklib-2.8.3-r1 Sat Jul 16 21:33:58 2005 >>> sys-libs/pam-0.78-r2 Note: genlop does not show when portage is emerged so I had to look it up in emerge.log and insert it in the output. ----- Here is the output of 'mount' for my workstation, which is having sandbox violations---actual servers, IPs, groups and users were changed: # mount /dev/hda2 on / type reiserfs (rw,noatime,acl) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) udev on /dev type tmpfs (rw,nosuid) devpts on /dev/pts type devpts (rw) /dev/hda1 on /boot type reiserfs (ro,noatime,acl,notail) /dev/vg00/opt on /opt type reiserfs (rw,noatime,acl) /dev/vg00/tmp on /tmp type reiserfs (rw,noatime,acl) /dev/vg00/usr on /usr type reiserfs (rw,noatime,acl) /dev/vg00/var on /var type reiserfs (rw,noatime,acl) /dev/vg00/data01 on /var/multimedia type reiserfs (rw,noatime,acl) /dev/vg01/home-video on /var/multimedia/home-video type reiserfs (rw,noatime,acl) /dev/vg01/vmware on /var/opt/vmware type reiserfs (rw,noatime,acl) tmpfs on /dev/shm type tmpfs (rw) usbfs on /proc/bus/usb type usbfs (rw,devmode=0666) nfsserver:/home on /home type nfs (rw,intr,retry=1,bg,rsize=8192,wsize=8192,soft,addr=XXX.XXX.XXX.XXX) nfsserver:/usr/portage on /usr/portage type nfs (ro,intr,retry=1,bg,rsize=8192,wsize=8192,soft,addr=XXX.XXX.XXX.XXX) nfsserver:/usr/local/share/data on /usr/local/share/data type nfs (rw,intr,retry=1,bg,rsize=8192,wsize=8192,soft,addr=XXX.XXX.XXX.XXX) /dev/hdc on /media/cdrom type iso9660 (ro,nosuid,nodev,user=clientuser) ----- Here is the output of 'emerge info' for my server, which is NOT having sandbox violations: # emerge info Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r0, 2.6.11-gentoo-r6 i686) ================================================================= System uname: 2.6.11-gentoo-r6 i686 AMD Athlon(tm) processor Gentoo Base System version 1.6.12 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.10 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.5 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="-march=athlon-tbird -mmmx -m3dnow -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/X11/*/app-defaults /etc/X11/app-defaults /etc/X11/rstart/rstartd.real /etc/X11/xdm /etc/X11/xdm/chooser /etc/gconf /etc/init.d /etc/openldap/schema /etc/terminfo /usr/X11R6/lib/X11/xkb /etc/env.d" CXXFLAGS="-march=athlon-tbird -mmmx -m3dnow -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/local/share/data/pub/linux/gentoo/distfiles" FEATURES="autoconfig buildpkg ccache distcc distlocks fixpackages sandbox sfperms strict userpriv" GENTOO_MIRRORS="http://www.ibiblio.org/pub/Linux/distributions/gentoo http://csociety-ftp.ecn.purdue.edu/pub/gentoo" LANG="en_US" LINGUAS="en" MAKEOPTS="-j5" PKGDIR="/usr/local/share/data/pub/linux/gentoo/packages/athlon-tbird" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/share/data/pub/linux/gentoo/portage /usr/local/share/data/pub/linux/gentoo/portage-bmg" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acl apache2 apm berkdb bitmap-fonts cgi crypt cscope cups curl emboss foomaticdb gd gdbm gpm imagemagick imap ipv6 java jpeg lcms ldap libg++ libwww logrotate mmx mysql ncurses pam pcre perl png pwdb python readline samba sasl slang snmp spell ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts userlocales vhosts zlib linguas_en userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS ----- Here is the merge history for the 16th on my server: Sat Jul 16 18:47:04 2005 >>> app-arch/bzip2-1.0.3-r4 Sat Jul 16 18:51:38 2005 >>> app-arch/gzip-1.3.5-r8 Sat Jul 16 18:58:20 2005 >>> app-shells/bash-3.0-r12 Sat Jul 16 18:59:42 2005 >>> sys-devel/gcc-config-1.3.11-r4 Sat Jul 16 19:04:38 2005 >>> sys-libs/zlib-1.2.2-r1 Sat Jul 16 19:09:20 2005 >>> sys-kernel/linux-headers-2.6.11-r2 Sat Jul 16 21:26:17 2005 >>> sys-libs/glibc-2.3.5 Sat Jul 16 21:27:26 2005 >>> sys-devel/autoconf-wrapper-3-r1 Sat Jul 16 21:32:13 2005 >>> sys-libs/cracklib-2.8.3-r1 Sat Jul 16 21:38:33 2005 >>> sys-libs/pam-0.78-r2 Sat Jul 16 21:39:51 2005 >>> sys-apps/sandbox-1.2.10 Sat Jul 16 21:41:26 2005 >>> sys-apps/portage-2.0.51.22-r1 Sat Jul 16 21:53:14 2005 >>> sys-apps/shadow-4.0.7-r3 Sat Jul 16 21:57:36 2005 >>> sys-apps/pam-login-3.17 Sat Jul 16 22:02:35 2005 >>> sys-libs/com_err-1.38 Sat Jul 16 22:07:18 2005 >>> sys-libs/ss-1.38 Sat Jul 16 22:09:40 2005 >>> sys-devel/libtool-1.5.18-r1 Sat Jul 16 23:18:47 2005 >>> x11-base/xorg-x11-6.8.2-r2 Sat Jul 16 23:19:49 2005 >>> app-arch/rpm2targz-9.0-r3 Sat Jul 16 23:27:20 2005 >>> sys-apps/man-1.6-r1 Sat Jul 16 23:32:03 2005 >>> sys-apps/kbd-1.12-r5 Sat Jul 16 23:33:41 2005 >>> sys-fs/udev-058 Again note: genlop does not show when portage is emerged so I had to look it up in emerge.log and insert it in the output. ----- Here is the output of 'mount' for my server, which is NOT having sandbox violations---actual servers, IPs, groups and users were changed: # mount /dev/hda3 on / type reiserfs (rw,acl) none on /proc type proc (rw,acl) none on /sys type sysfs (rw) none on /dev type ramfs (rw) none on /dev/pts type devpts (rw) /dev/hda2 on /boot type reiserfs (rw,acl,notail) tmpfs on /dev/shm type tmpfs (rw) /dev/hdb1 on /home type ext3 (rw,acl) /dev/vg01/data on /usr/local/share/data type reiserfs (rw,acl) none on /proc/bus/usb type usbfs (rw) nfsd on /proc/fs/nfs type nfsd (rw) -----
(In reply to comment #18) > I can confirm this problem is not fixed. I originally reported sandbox > violations in bug #96568 and later marked it as a dup of this one. > > As documented in bug #96568, I downgraded to a stable version of portage and the > problem went away. That's almost exactly what happened to me to discover this issue except that, for me, the buggy version had become stable (so I downgraded to the previous stable version.) > Now that portage 2.0.51.22-r1 has been marked stable the problem has resurfaced. > I did a 'emerge -Dub system' on the 16th and the sandbox violations started to > occur again shortly after portage 2.0.51.22-r1 was installed. This time I got a > sandbox violation on sys-apps/shadow-4.0.7-r3. > >[snip] > > The interesting thing is I have a server with the same FEATURES enabled and > after the upgrade to portage 2.0.51.22-r1 none of the packages afterward > produced sandbox violations---not even sys-apps/shadow-4.0.7-r3. I have two > other test boxes but have not upgraded on then yet. There has to be something common among those who experience this bug. Harald and I both noted that we're mounting our filesystems with the bsdgroups flag, which makes the group of new files be the group of the parent directory. (The default is to have the group of new files be the group of the process creating them.) bsdgroups is ext2/3 only, and I'm not familiar with reiserfs. Is there any chance some of the filesystems you use (specifically the ones where portage is building things on, /var/tmp/portage unless you've changed it in make.conf) have a similar flag? >[snip]
(In reply to comment #19) > There has to be something common among those who experience this bug. Harald and I both noted > that we're mounting our filesystems with the bsdgroups flag, which makes the group of new files be the > group of the parent directory. (The default is to have the group of new files be the group of the process > creating them.) bsdgroups is ext2/3 only, and I'm not familiar with reiserfs. Is there any chance some of > the filesystems you use (specifically the ones where portage is building things on, /var/tmp/portage > unless you've changed it in make.conf) have a similar flag? I looked at the mount man page but did not see an option similar to bsdgroups for reiserfs and, if memory serves me correctly, I seem to remember files are created with the group of the process on reiserfs. However, I do not believe the problem lies with the mount options. In my case, both systems use the same mount options for the file system containing PORTAGE_TMPDIR (/var/tmp). The only difference between my systems as far as PORTAGE_TMPDIR is concerned is my workstation mounts a file system on /var and, on my server, /var is a part of /. That, and my workstation is a nfs client of the server but only DISTDIR, PKGDIR and PORTDIR_OVERLAY are located on nfs mounts. The only thing I can think of that might be causing this problem is an old file not removed by older versions of portage that were unmerged.
(In reply to comment #20) > I looked at the mount man page but did not see an option similar to bsdgroups > for reiserfs and, if memory serves me correctly, I seem to remember files are > created with the group of the process on reiserfs. Makes sense; that's the default for Linux. ext2/3 is the only fs I've seen with an option like bsdgroups. > However, I do not believe the problem lies with the mount options. In my case, > both systems use the same mount options for the file system containing > PORTAGE_TMPDIR (/var/tmp). > > The only difference between my systems as far as PORTAGE_TMPDIR is concerned is > my workstation mounts a file system on /var and, on my server, /var is a part of > /. That, and my workstation is a nfs client of the server but only DISTDIR, > PKGDIR and PORTDIR_OVERLAY are located on nfs mounts. Darn. I was hoping that could be identified as the cause. It does somewhat make sense that an option that fiddles with the default group-owner of symlinks would cause Portage to try and change them to something else. Though we don't know what causes the bug to only happen for certain people, we do know that it is, in fact, a bug; I think it could be resolved if we created a patch (apparently to ebuild.sh) to run chown/ chgrp/chmod such that it won't dereference symlinks. On OS X, the -h option is available for all 3, but it seems to not exist for GNU chmod. Should the severity of this bug be increased, or left at normal because there's a workaround (downgrading Portage)?
Patch committed and released in 2.0.51.22-r2. Will hit the (up-to-date) mirrors in approximately 30 minutes.
*** Bug 99616 has been marked as a duplicate of this bug. ***
OK, after doing some further research on my test box, I believe I've found the source of my sandbox violations. First, however, I'll need to explain my setup. I installed and set up my server as a private portage mirror back in 2003 and 5 machines use the server's portage tree. The way the 5 machines obtain information from the portage tree isn't via rsync but they nfs mount the portage tree onto /usr/portage from the server. The machines also store packages and distfiles on a different nfs share from portage. On the server, the nfs shares are set up with the root_squash mapping option for security reasons. Plus, the paths used to store packages and distfiles have a group ownership of portage and group permissions of rws. The reason for this is so users, which are a member of the portage group, can fetch files without having to be root or use sudo. On all of the machines, I've set up sudo so that members of the portage group can run several commands related to package management as root without actually logging in as root. I have it setup this way for security reasons. ----- With the explanation of the setup out of the way, here is how package management used to work on any of the machines. A member of the portage group would install a package by running 'sudo emerge packagename' and never have to be root. Portage would download source files from a Gentoo mirror, store the source files on the nfs share used for packages and distfiles, build the packages, and save a binary package file if requested. This worked flawlessly as explained for about 2 years until a portage upgrade earlier this year broke it. When the portage upgrade was installed, users could no longer use sudo. emerge would report it did not have write access to DISTDIR and PKGDIR then quit. If emerge was run while directly logged in as root, it would also report the same thing. I figured this was due to the root_squash option on the nfs shares and portage was changed so that files are no longer fetched as the portage user so I submitted bug #94133. In the meantime, I started running emerge directly as root but did a 'sg - portage' first to get around the root_squash option on the nfs shares. Through my testing I have determined it is this 'sg - portage' that is causing the sandbox violations with portage-2.0.51.22-r1.
