It appears to try and write or remove all .xauth files in ~root Reproducible: Always Steps to Reproduce: 1. try to merge the package Actual Results: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-gnustep-base_-_gnustep-make-1.10.1_pre20041030-r1-30409.log" open_wr: /root/.xauthDiCL0u-c open_wr: /root/.xauthDiCL0u-c open_wr: /root/.xauthDiCL0u-c open_wr: /root/.xauthDiCL0u-c open_wr: /root/.xauthDiCL0u-c open_wr: /root/.xauthDiCL0u-c open_wr: /root/.xauthDiCL0u-c open_wr: /root/.xauthDiCL0u-c open_wr: /root/.xauthDiCL0u-c open_wr: /root/.xauthDiCL0u-c -------------------------------------------------------------------------------- Expected Results: Uhh, no access violations :) I thought at first that this would only happen when merging with some real xauth data already there, but that was not the case.
Works when run from a vc instead of from inside X.
1) Please include the output of `emerge info` 2) Do you have anything in an overlay? 3) ... actually, just include `emerge info`, and a lot of my questions will be answered I haven't been able to recreate this in a terminal (real one, where I do all my testing anyway) w/ and w/o userpriv/usersandbox or in X with the same options.
I have nothing in overlay. Portage 2.0.51-r3 (default-linux/x86/2004.0, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9 i686) ================================================================= System uname: 2.6.9 i686 AMD Athlon(tm) MP 2100+ Gentoo Base System version 1.6.6 distcc 2.18 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux-headers-2.4.22,sys-kernel/linux-headers-2.4.19-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -fgcse -fgcse-lm -fgcse-sm -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /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/bind /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -fgcse -fgcse-lm -fgcse-sm -fomit-frame-pointer -pipe -Wno-deprecated" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache cvs distcc distlocks sandbox sfperms usersandbox" GENTOO_MIRRORS="http://gentoo.seren.com/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo" MAKEOPTS="-j8" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex X aalib acpi alsa apache2 avi berkdb bitmap-fonts cdparanoia cdr crypt cups curl dga directfb divx4linux dvd dvdread encode ethereal fbcon flash gd gdbm ggi gif gimpprint gphoto2 gpm gtk gtk2 gtkhtml imap imlib innodb java jbig jikes jpeg libg++ libwww mad mbox mmx mozilla mpeg mysql ncurses objc oci8 oggvorbis opengl pam pcmcia pdflib perl plotutils png pnp postgres python quicktime readline samba sdl spell sse ssl svga tcltk tetex tiff truetype usb xinerama xml xml2 xmms xprint xv zlib"
If you would, please try this, and report back... (assuming your setup is right now as in your posted emerge info) # Is something just currently messed up? 1) rm -Rf /var/tmp/portage/* (Clear out tmp files, just in case) 2) Try again ("just in case" it works now) # when emerging cvs.eclass inheriting ebuilds, does "userpriv" _have_ to be set? 1) add "userpriv" to FEATURES in /etc/make.conf (alongside usersandbox) 2) rm -Rf /var/tmp/portage/* 3) chown -R portage:portage /usr/portage/distfiles/cvs-src 4) emerge -pv gnustep-make Note that if it succeeds with the above steps, please post and let me know, as there's likely something that needs to be addressed between userpriv and the cvs.eclass. My guess is that root's cvs account is setup, or was set up at one point, to utilize some X resource, and when running as root in a sandbox, $HOME is still /root ... hopefully 'userpriv' will help this. Let me know, and thanks!
Here's all the output from doing those steps. lost ~ # rm -rf /var/tmp/portage lost ~ # emerge gnustep-make Calculating dependencies ...done! >>> emerge (1 of 1) gnustep-base/gnustep-make-1.10.1_pre20041030-r1 to / * GNUstep installation will be laid out thusly: * GNUSTEP_SYSTEM_ROOT=/usr/GNUstep/System * GNUSTEP_LOCAL_ROOT=/usr/GNUstep/Local * GNUSTEP_NETWORK_ROOT=/usr/GNUstep/Network * GNUSTEP_USER_ROOT=~/GNUstep >>> Unpacking source... * Fetching CVS module gnustep/core/make into /usr/portage/distfiles/cvs-src/savannah.gnu.org-gnustep ... * Warning: The SSH host key of the remote server will not be verified. * A temporary known hosts list will be used. * Running cvs -q -d ":ext:anoncvs@savannah.gnu.org:/cvsroot/gnustep" update -dP -D 20041030 gnustep/core/make Warning: Permanently added 'savannah.gnu.org,199.232.41.3' (RSA) to the list of known hosts. Warning: No xauth data; using fake authentication data for X11 forwarding. * Copying gnustep/core/make from /usr/portage/distfiles/cvs-src/savannah.gnu.org-gnustep ... * CVS module gnustep/core/make is now in /var/tmp/portage/gnustep-make-1.10.1_pre20041030-r1/work * Applying make-user-defaults.patch-1.10.0 ... [ ok ] * Applying GNUstep-reset.sh.patch ... [ ok ] >>> Source unpacked. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-gnustep-base_-_gnustep-make-1.10.1_pre20041030-r1-18944.log" open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c -------------------------------------------------------------------------------- lost ~ # rm -rf /var/tmp/portage lost ~ # chown -R portage:portage /usr/portage/distfiles/cvs-src/ lost ~ # FEATURES="userpriv usersandbox" emerge gnustep-make Calculating dependencies ...done! >>> emerge (1 of 1) gnustep-base/gnustep-make-1.10.1_pre20041030-r1 to / * GNUstep installation will be laid out thusly: * GNUSTEP_SYSTEM_ROOT=/usr/GNUstep/System * GNUSTEP_LOCAL_ROOT=/usr/GNUstep/Local * GNUSTEP_NETWORK_ROOT=/usr/GNUstep/Network * GNUSTEP_USER_ROOT=~/GNUstep >>> Unpacking source... * Fetching CVS module gnustep/core/make into /usr/portage/distfiles/cvs-src/savannah.gnu.org-gnustep ... * Warning: The SSH host key of the remote server will not be verified. * A temporary known hosts list will be used. * Running cvs -q -d ":ext:anoncvs@savannah.gnu.org:/cvsroot/gnustep" update -dP -D 20041030 gnustep/core/make ACCESS DENIED mkdir: /home/portage/.ssh Could not create directory '/home/portage/.ssh'. Warning: Permanently added 'savannah.gnu.org,199.232.41.3' (RSA) to the list of known hosts. Warning: No xauth data; using fake authentication data for X11 forwarding. * Copying gnustep/core/make from /usr/portage/distfiles/cvs-src/savannah.gnu.org-gnustep ... * CVS module gnustep/core/make is now in /var/tmp/portage/gnustep-make-1.10.1_pre20041030-r1/work * Applying make-user-defaults.patch-1.10.0 ... [ ok ] * Applying GNUstep-reset.sh.patch ... [ ok ] >>> Source unpacked. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-gnustep-base_-_gnustep-make-1.10.1_pre20041030-r1-19199.log" mkdir: /home/portage/.ssh open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c open_wr: /root/.xauthtwEn9E-c --------------------------------------------------------------------------------
Brandon, Two things were strange when you added that FEATURES like on the command line. The access violsations where still for root, and the ebuild was tring to access /home/portage. Did you change /etc/passwd's portage entry? HOME should be /var/tmp/portage Could you please temporarily ACTUALLY added userpriv and usersandbox to /etc/make.conf, and try that last step again? Note that you can always install the non _pre* version of the ebuild, avoiding this problem entirely.
I don't even use the package (afaik) just filing the bug because it's the kind of thing that should get fixed :) I'll play with it more when I'm next on the effected machine. It could also be that my /etc/passwd is outdated as this system was installed more than 2 years ago, I'll take a look into that as well.
lost ~ # emerge gnustep-make Calculating dependencies ...done! >>> emerge (1 of 1) gnustep-base/gnustep-make-1.10.1_pre20041030-r1 to / * GNUstep installation will be laid out thusly: * GNUSTEP_SYSTEM_ROOT=/usr/GNUstep/System * GNUSTEP_LOCAL_ROOT=/usr/GNUstep/Local * GNUSTEP_NETWORK_ROOT=/usr/GNUstep/Network * GNUSTEP_USER_ROOT=~/GNUstep >>> Unpacking source... * Fetching CVS module gnustep/core/make into /usr/portage/distfiles/cvs-src/savannah.gnu.org-gnustep ... * Warning: The SSH host key of the remote server will not be verified. * A temporary known hosts list will be used. * Running cvs -q -d ":ext:anoncvs@savannah.gnu.org:/cvsroot/gnustep" update -dP -D 20041030 gnustep/core/make Warning: Permanently added 'savannah.gnu.org,199.232.41.3' (RSA) to the list of known hosts. Warning: No xauth data; using fake authentication data for X11 forwarding. * Copying gnustep/core/make from /usr/portage/distfiles/cvs-src/savannah.gnu.org-gnustep ... * CVS module gnustep/core/make is now in /var/tmp/portage/gnustep-make-1.10.1_pre20041030-r1/work * Applying make-user-defaults.patch-1.10.0 ... [ ok ] * Applying GNUstep-reset.sh.patch ... [ ok ] >>> Source unpacked. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-gnustep-base_-_gnustep-make-1.10.1_pre20041030-r1-32256.log" open_wr: /root/.xauthFIMxqX-c open_wr: /root/.xauthFIMxqX-c open_wr: /root/.xauthFIMxqX-c open_wr: /root/.xauthFIMxqX-c open_wr: /root/.xauthFIMxqX-c open_wr: /root/.xauthFIMxqX-c open_wr: /root/.xauthFIMxqX-c open_wr: /root/.xauthFIMxqX-c open_wr: /root/.xauthFIMxqX-c open_wr: /root/.xauthFIMxqX-c -------------------------------------------------------------------------------- lost ~ # grep '^FEATURES' /etc/make.conf FEATURES="sandbox distcc ccache usersandbox buildpkg cvs userpriv" lost ~ # emerge --info|grep FEATURES FEATURES="autoaddcvs autoconfig buildpkg ccache cvs distcc distlocks sandbox sfperms userpriv usersandbox"
This appears gone in some new version.
Ahh, excellent. I forgot to tag this bug closed after some CVS fixes on other/many related bugs. Good to here that the cvs.eclass changes are working though.
