Portage permissions within /var/tmp/portage become erratic and hinder usage when debugging a program with GDB. localhost2 ~ # ls -al /var/tmp/portage/ total 16K drwxrwxr-x 4 portage portage 4.0K Oct 20 23:14 ./ drwxrwxrwt 5 root root 4.0K Oct 20 20:11 ../ drwxrwxr-x 2 portage portage 4.0K Oct 20 23:14 ._unmerge_/ drwxrwxr-x 3 portage portage 4.0K Oct 20 23:14 app-cdr/ 0 ;-) localhost2 ~ # ls -al /var/tmp/portage/app-cdr/ total 12K drwxrwxr-x 3 portage portage 4.0K Oct 20 23:14 ./ drwxrwxr-x 4 portage portage 4.0K Oct 20 23:14 ../ drwxrwxr-x 8 portage portage 4.0K Oct 20 23:14 cdw-0.7.0/ 0 ;-) /* We're OK with permissions up until the point when a package is uncompressed, and then we fall apart and use root.root. */ localhost2 ~ # ls -al /var/tmp/portage/app-cdr/cdw-0.7.0/ total 32K drwxrwxr-x 8 portage portage 4.0K Oct 20 23:14 ./ drwxrwxr-x 3 portage portage 4.0K Oct 20 23:14 ../ drwxr-xr-x 2 root root 4.0K Oct 20 23:13 build-info/ drwxr-xr-x 2 root portage 4.0K Oct 20 23:10 distdir/ drwxrwxr-x 2 portage portage 4.0K Oct 20 23:14 homedir/ drwxr-xr-x 3 root root 4.0K Oct 20 23:13 image/ drwxrwxr-x 3 portage portage 4.0K Oct 20 23:13 temp/ drwx------ 3 portage portage 4.0K Oct 20 23:10 work/ -rw-r--r-- 1 root root 0 Oct 20 23:13 .compiled -rw-r--r-- 1 root root 0 Oct 20 23:12 .configured prwxrwx--- 1 root portage 0 Oct 20 23:14 .ipc_in| prwxrwx--- 1 root portage 0 Oct 20 23:14 .ipc_out| -rw-r--r-- 1 root root 0 Oct 20 23:13 .packaged -rw-r--r-- 1 root root 0 Oct 20 23:11 .prepared -rw-r--r-- 1 root root 0 Oct 20 23:10 .setuped -rw-r--r-- 1 root root 0 Oct 20 23:10 .unpacked At this point, when using "CFLAGS="-g -Wall -ggdb" CXXFLAGS="${CFLAGS}" FEATURES="nostrip noclean" USE="debug" emerge $1" to compile a package, I cannot run GDB as a user because it does not have access to the code sources within the above files due to permissions. I need to run GDB as root to access those sources, and then the "list" command will finally list the sources. (The above emerge line with environmental variables, is within a bash script I use to enable all debug features for compiling a package for debugging with GDB. Substitute $1 for package name.) Reproducible: Always My current FEATURES within /etc/make.conf: FEATURES="collision-protect strict fixpackages buildpkg parallel-fetch sandbox userfetch -userpriv usersandbox userfetch"
I'm guessing, I *should* see everything within /var/tmp/portage owned by portage.portage. And then I should be able to add my user to the portage group within /etc/groups, and then have access to the sources within /var/tmp/portage.
I'm a little further along on this, and find changing the following folder/file ownership/permissions to the following are more suitable: chown -R portage.portage /var/tmp/portage/app-cdr/cdw-0.7.0 chmod -R g+Xr /var/tmp/portage/app-cdr/cdw-0.7.0 I now can enter & view the sources as user, when given portage group read permissions. (However, I'm curious on one issue. I can easily use "gdb list command" to view source listings from any folder as root/superuser. However, I cannot do "gdb list" to see the source listing as simple user from any folder, even with portage read permissions. To do "gdb list", I must first "cd /var/tmp/portage/app-cdr/cdw-0.7.0/work/cdw-0.7.0/src/" before being able to successfully use "gdb list". I'm missing something -- .gdbinit has been moved/emptied!)
Could you confirm (and preferably attach) the output of emerge --info when using your debug wrapper script? There is a (slim) possibility that you are overwriting FEATURES instead of appending...
$ emerge --info FEATURES="assume-digests binpkg-logs buildpkg collision-protect distlocks ebuild-locks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch usersandbox" $ cat /etc/make.conf |grep FEATURES FEATURES="collision-protect strict fixpackages buildpkg parallel-fetch sandbox splitdebug userfetch -userpriv usersandbox userfetch" $ cat /home/roger/bin/emerge_debug.sh |grep FEATURES CFLAGS="-g -Wall -ggdb" CXXFLAGS="${CFLAGS}" FEATURES="nostrip noclean" USE="debug" emerge $1
It's a security vulnerability to allow read access to WORKDIR, since it may contain files with insecure permissions (see bug #8688). You can set the PORTAGE_WORKDIR_MODE variable in make.conf if you want to have insecure permissions by default. This variable is documented in `man make.conf`. Also, you might be interested in using FEATURES="installsources splitdebug".
Looking over this again, when a package is unzipped/untarred it is performed as root with root permissions rw-r-r (or 0700). A better method is to unzip/untar as user portage with rw-rw-r (or 0770) and then allow users to be added to the portage group. For some reason or another, the initial /var/tmp/portage/package-cat/package-name does initially get created owned by portage, but then switches to untar/unzip with root permissions as noted above. Thanks for the additional info on FEATURES="installsources splitdebug". I already have splitdebug active here as it only uses an additional few megabytes of space while giving my symbols when using gdb. installsources would be great if there were an easy method of using it instead of creating /etc/portage/env/ for each package. (Supposedly this is an unsupported hack using /etc/portage/env/.)
(In reply to comment #6) > Looking over this again, when a package is unzipped/untarred it is performed > as root with root permissions rw-r-r (or 0700). A better method is to > unzip/untar as user portage with rw-rw-r (or 0770) and then allow users to > be added to the portage group. If you enable FEATURES=userpriv then it will do it. > For some reason or another, the initial > /var/tmp/portage/package-cat/package-name does initially get created owned > by portage, but then switches to untar/unzip with root permissions as noted > above. > > > Thanks for the additional info on FEATURES="installsources splitdebug". I > already have splitdebug active here as it only uses an additional few > megabytes of space while giving my symbols when using gdb. installsources > would be great if there were an easy method of using it instead of creating > /etc/portage/env/ for each package. (Supposedly this is an unsupported hack > using /etc/portage/env/.) This is supported by /etc/portage/package.env, which is mentioned in "How do I configure environment variable settings that apply only to specific packages?" section of the FAQ located at http://www.gentoo.org/proj/en/portage/doc/faq.xml.
If I'm not mistaken, changing the root to portage ownership for untarred/unzipped files sounds like it might introduce a "chicken before the egg" syndrome. Hence, when doins is called from the ebuild, it might install package files as owned/group of portage installed of default root. Anyways, using FEATURES="userpriv" for kernel module package/ebuilds introduces the following non-descriptive bug. My current FEATURES are FEATURES="collision-protect strict buildpkg parallel-fetch sandbox splitdebug userfetch userpriv usersandbox". (According to my notes within make.conf, there may also be problems when trying to incorporate portage using NFS on clients.) app-emulation/virtualbox-modules-4.1.8 make[1]: Entering directory `/var/tmp/portage/app-emulation/virtualbox-modules-4.1.8/work/vboxdrv' make KBUILD_VERBOSE= SUBDIRS=/var/tmp/portage/app-emulation/virtualbox-modules-4.1.8/work/vboxdrv SRCROOT=/var/tmp/portage/app-emulation/virtualbox-modules-4.1.8/work/vboxdrv CONFIG_MODULE_SIG= -C /usr/src/linux modules make[2]: Entering directory `/usr/src/linux-3.1.10-gentoo-r1' Makefile:1553: ..tmp_kallsyms1.o.cmd: Permission denied Makefile:1553: ..tmp_kallsyms2.o.cmd: Permission denied media-libs/svgalib-1.9.25-r2 make[1]: Leaving directory `/var/tmp/portage/media-libs/svgalib-1.9.25-r2/work/svgalib-1.9.25/threeDKit' * Preparing svgalib_helper module make -j1 HOSTCC=i686-pc-linux-gnu-gcc CROSS_COMPILE=i686-pc-linux-gnu- LDFLAGS= KDIR=/lib/modules/3.1.10-gentoo-r1/build default make -C /lib/modules/3.1.10-gentoo-r1/build SUBDIRS=/var/tmp/portage/media-libs/svgalib-1.9.25-r2/work/svgalib-1.9.25/kernel/svgalib_helper CLASS_CFLAGS= modules make[1]: Entering directory `/usr/src/linux-3.1.10-gentoo-r1' Makefile:1553: ..tmp_kallsyms1.o.cmd: Permission denied Makefile:1553: ..tmp_kallsyms2.o.cmd: Permission denied CC [M] /var/tmp/portage/media-libs/svgalib-1.9.25-r2/work/svgalib-1.9.25/kernel/svgalib_helper/main.o /var/tmp/portage/media-libs/svgalib-1.9.25-r2/work/svgalib-1.9.25/kernel/svgalib_helper/main.c:1:0: error: CPU you selected does not support x86-64 instruction set make[2]: *** [/var/tmp/portage/media-libs/svgalib-1.9.25-r2/work/svgalib-1.9.25/kernel/svgalib_helper/main.o] Error 1 make[1]: *** [_module_/var/tmp/portage/media-libs/svgalib-1.9.25-r2/work/svgalib-1.9.25/kernel/svgalib_helper] Error 2 make[1]: Leaving directory `/usr/src/linux-3.1.10-gentoo-r1' make: *** [default] Error 2 x11-drivers/nvidia-drivers-290.10-r2 * Preparing nvidia module make -j1 HOSTCC=i686-pc-linux-gnu-gcc CROSS_COMPILE=i686-pc-linux-gnu- LDFLAGS= IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/3.1.10-gentoo-r1/build CC=i686-pc-linux-gnu-gcc clean module If you are using a Linux 2.4 kernel, please make sure you either have configured kernel sources matching your ...snip... Depending on where and how the kernel sources (or the kernel headers) were installed, you may need to specify their location with the SYSSRC environment variable or the equivalent nvidia-installer command line option. *** Unable to determine the target kernel version. *** make: *** [select_makefile] Error 1 emake failed * ERROR: x11-drivers/nvidia-drivers-290.10-r2 failed (compile phase): * Unable to emake HOSTCC=i686-pc-linux-gnu-gcc CROSS_COMPILE=i686-pc-linux-gnu- LDFLAGS= IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/3.1.10-gentoo-r1/build CC=i686-pc-linux-gnu-gcc clean module * * Call stack: * ebuild.sh, line 85: Called src_compile * environment, line 3686: Called linux-mod_src_compile * environment, line 2643: Called die * The specific snippet of code: * eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" CROSS_COMPILE=${CHOST}- LDFLAGS=\"$(get_abi_LDFLAGS)\" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS} " || die "Unable to emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}";
(In reply to comment #8) > If I'm not mistaken, changing the root to portage ownership for > untarred/unzipped files sounds like it might introduce a "chicken before the > egg" syndrome. Hence, when doins is called from the ebuild, it might > install package files as owned/group of portage installed of default root. That's not a problem because the portage uid and gid are automatically mapped to root uid and gid after src_install. I've had FEATURES=userpriv enabled for years and I practically never have any problems related to it. > Anyways, using FEATURES="userpriv" for kernel module package/ebuilds > introduces the following non-descriptive bug. Either the kernel sources aren't configured properly, or the ebuild is buggy. All that you should need to configure your sources properly (as root) is this: cd /usr/src/linux && make oldconfig modules_prepare After that, kernel module builds with FEATURES=userpriv should work fine, assuming the ebuild is not buggy.
(In reply to comment #9) >> Anyways, using FEATURES="userpriv" for kernel module package/ebuilds >> introduces the following non-descriptive bug. >Either the kernel sources aren't configured properly, or the ebuild is buggy. >All that you should need to configure your sources properly (as root) is this: > cd /usr/src/linux && make oldconfig modules_prepare > After that, kernel module builds with FEATURES=userpriv should work fine, > assuming the ebuild is not buggy. Negative. Like I stated prior, the error is misleading. Kernel sources are installed and configured, built and installed properly. # ls -alh /usr/src/linux lrwxrwxrwx 1 root root 22 Feb 20 00:37 /usr/src/linux -> linux-3.1.10-gentoo-r1/ # uname -a Linux localhost2.local 3.1.10-gentoo-r1 #2 SMP PREEMPT Mon Feb 20 02:11:45 AKST 2012 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux All three ebuilds are not all likely faulty. =sys-apps/portage-2.1.10.44 FEATURES="collision-protect strict buildpkg parallel-fetch sandbox splitdebug userfetch userpriv usersandbox" ... again, the error is misleading and traces back to using userpriv (or maybe another FEATURE keyword). Using "-userpriv" solves the error with ebuild module building. If I had more time, I could trace this further back to the exact snippet of code.
See bug #137773 for kernel module ebuilds and userpriv incompatibility. My server/client emerge world update scripts only chmod/chown /usr/portage/packages so they can be readable by ftp/clients to the best of my knowledge. # touch me && ls -al me -rw-r--r-- 1 root root 0 Mar 7 17:49 me # umask -p umask 0022 And yet, /usr/src/linux/.config is created with the following permissions. # ls -alh /usr/src/linux/.config -rw------- 1 root root 87K Feb 20 00:41 /usr/src/linux/.config
(In reply to comment #11) > See bug #137773 for kernel module ebuilds and userpriv incompatibility. That counts as an "ebuild bug", since the ebuild or eclass functions that it uses should check for appropriate permissions as suggested in bug 137773, comment #16.
lol. I agree. I'm cc'd on that one as well now too.
