Created attachment 413580 [details] emerge output example On a particular arm system installed about two years ago, when running emerge, I'm finding sometimes some strange « Permission denied » errors. Such messages can appear at each emerge phase, but not on every package. Recently I noticed that this starts to appear when «Calculating dependencies». This sounds like permissions issues, but despite my research, these errors persist. Except this problem, emerge and the overall system are working fine. The portage tree is mounted over NFS. The system is up-to-date, and I'm using a distcc server to help this device. Please see the attached file to see how it can affect the emerge output. Does anyone have an idea and tell me what's going on here please ? Thanks ! # emerge --info Portage 2.2.20.1 (python 3.4.1-final-0, default/linux/arm/13.0/armv7a, gcc-4.9.3, glibc-2.20-r2, 3.4.108+ armv7l) ================================================================= System uname: Linux-3.4.108+-armv7l-ARMv7_Processor_rev_4_-v7l-with-gentoo-2.2 KiB Mem: 913660 total, 50032 free KiB Swap: 262140 total, 248784 free Timestamp of repository gentoo: Sat, 03 Oct 2015 06:30:01 +0000 sh bash 4.3_p39 ld GNU ld (Gentoo 2.24 p1.4) 2.24 distcc 3.1 armv7a-hardfloat-linux-gnueabi [enabled] app-shells/bash: 4.3_p39::gentoo dev-lang/perl: 5.20.2::gentoo dev-lang/python: 2.7.9-r1::gentoo, 3.4.1::gentoo dev-util/cmake: 3.2.2::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.17::gentoo sys-apps/sandbox: 2.6-r1::gentoo sys-devel/autoconf: 2.69::gentoo sys-devel/automake: 1.11.6-r1::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.24-r3::gentoo sys-devel/gcc: 4.8.5::gentoo, 4.9.3::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers) sys-libs/glibc: 2.20-r2::gentoo Repositories: gentoo location: /portage/trees/gentoo sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 cubieboard-overlay location: /portage/trees/cubieboard sync-type: git sync-uri: https://github.com/ksa242/gentoo-cubieboard-overlay.git masters: gentoo priority: 0 voyageur location: /portage/trees/voyageur sync-type: git sync-uri: https://cafarelli.fr/git/voyageur-overlay/ masters: gentoo priority: 0 Installed sets: @misc, @xfce ACCEPT_KEYWORDS="arm" ACCEPT_LICENSE="* -@EULA" CBUILD="armv7a-hardfloat-linux-gnueabi" CFLAGS="-O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard" CHOST="armv7a-hardfloat-linux-gnueabi" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.6/ext-active/ /etc/php/cgi-php5.6/ext-active/ /etc/php/cli-php5.6/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard" DISTDIR="/portage/distfiles/" EMERGE_DEFAULT_OPTS="--with-bdeps=y" FCFLAGS="-O2 -pipe -march=armv7-a" FEATURES="assume-digests binpkg-logs binpkg-multi-instance buildpkg config-protect-if-modified distcc distcc-pump distlocks ebuild-locks fixlafiles merge-sync news nodoc noinfo noman parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe -march=armv7-a" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="fr_FR.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j4" PKGDIR="/portage/packages/armv7-a/" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" USE="X arm armv5te armv6 armv6t2 berkdb bzip2 cli cracklib crypt cxx dbus dri ffmpeg fortran gdbm gles1 gles2 iconv ipv6 jpeg modules mp3 mysql ncurses nls nptl ogg openmp pam pcre png qt5 readline seccomp session ssl tcpd udev unicode v4l vorbis zlib" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="fr" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="sunxi" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Created attachment 413686 [details] today's output The funny thing is that, today, after the whole system update was done, the same exact command produce a normal output (see attached file).
Created attachment 413692 [details] webapp-config emerge log But, as you can see in this log file, this happens while reemerging app-admin/webapp-config.
... Personally, I've seen that kind of output if - for example - emerge was started from a dir, that got removed while emerge was running. Here, it's likely you've found some NFS quirk.
(In reply to Rafał Mużyło from comment #3) > Personally, I've seen that kind of output if - for example - emerge was > started from a dir, that got removed while emerge was running. I start emerge with root user from ~, but, while trying to track this issue I remember starting emerge from others directories with same results. (In reply to Rafał Mużyło from comment #3) > Here, it's likely you've found some NFS quirk. I don't know. On the same network I have another system which mount the same portage tree via NFS in the exact same way, no problem here.
Check if the problem goes away if you disable userpriv in make.conf like this: FEATURES="${FEATURES} -usrpriv"
(In reply to Zac Medico from comment #5) > Check if the problem goes away if you disable userpriv in make.conf like > this: > > FEATURES="${FEATURES} -usrpriv" You can also disable usersandbox and userfetch: FEATURES="${FEATURES} -usrpriv -usersandbox -userfetch"
(In reply to Zac Medico from comment #6) > FEATURES="${FEATURES} -usrpriv -usersandbox -userfetch" I spelled userpriv incorrectly there.
Re-emerging app-admin/webapp-config without any change make those errors appear again and again. Setting FEATURES="${FEATURES} -userpriv -usersandbox -userfetch" in make.conf makes them go away.
It seems that you have some directory permissions which trigger these 'Permission denied' issues with userpriv processes. One relevant directory might be the portage user's home directory specified in /etc/passwd, which is typically /var/tmp/portage. Another one is the path of portage's python libraries, which is the python site-packages directory located at /usr/lib64/python*/site-packages/. Note that the portage user needs access to all parent directories of those mentioned above.
/var/tmp/portage is mounted in tmpfs. /usr/lib is not a symlink because 32-bit platform. I don't see what can be the problem. Do you see something ? > $ grep portage: /etc/passwd > portage:x:250:250:portage:/var/tmp/portage:/bin/false > $ mount | grep portage > buildtmp on /var/tmp/portage type tmpfs (rw,relatime,size=685248k,mode=775,uid=250,gid=250) > $ ls -ld / /var /var/tmp /var/tmp/portage > drwxr-xr-x 23 root root 4096 30 juil. 13:40 / > drwxr-xr-x 11 root root 4096 20 août 2014 /var > drwxrwxrwt 4 root root 4096 4 oct. 12:23 /var/tmp > drwxrwxr-x 3 portage portage 60 4 oct. 22:05 /var/tmp/portage > $ ls -ld / /usr /usr/lib* /usr/lib*/python*/ /usr/lib*/python*/site-packages/ > drwxr-xr-x 23 root root 4096 30 juil. 13:40 / > drwxr-xr-x 14 root root 4096 2 août 17:27 /usr > drwxr-xr-x 63 root root 40960 3 oct. 16:49 /usr/lib > drwxr-xr-x 5 root root 4096 30 juil. 14:12 /usr/lib/python-exec/ > drwxr-xr-x 24 root root 20480 8 janv. 2015 /usr/lib/python2.7/ > drwxr-xr-x 10 root root 4096 4 oct. 22:00 /usr/lib/python2.7/site-packages/ > drwxr-xr-x 3 root root 4096 31 juil. 16:35 /usr/lib/python3.3/ > drwxr-xr-x 5 root root 4096 31 juil. 16:35 /usr/lib/python3.3/site-packages/ > drwxr-xr-x 33 root root 4096 30 juil. 13:42 /usr/lib/python3.4/ > drwxr-xr-x 10 root root 4096 4 oct. 22:00 /usr/lib/python3.4/site-packages/ > drwxr-xr-x 3 root root 4096 4 oct. 11:42 /usr/lib64 > drwxr-xr-x 7 root root 4096 3 oct. 16:48 /usr/libexec
I hate to kick this poor zombie of a bug, but I want to document one scenario for which I can recreate this issue, and I also have a solution, just in case someone else runs into something similar. I can recreate this bug at will now, and it has nothing to do with userpriv, at least not on current/recent gentoo systems, at least for me. I'm not sure that this is a bug, but rather a consequence of the environment. Like many people, I build gentoo inside a chroot environment, in which I run commands as root. /source/tst1/tst2 # ll total 8 drwxr-x--- 2 man man 4096 May 25 07:35 . drwxr-x--- 3 man man 4096 May 25 07:35 .. /source/tst1/tst2 # ebuild /usr/portage/acct-group/users/users-0-r1.ebuild setup shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied /source/tst1/tst2 # chmod o+x . .. /source/tst1/tst2 # ebuild /usr/portage/acct-group/users/users-0-r1.ebuild clean /source/tst1/tst2 # ebuild /usr/portage/acct-group/users/users-0-r1.ebuild setup /source/tst1/tst2 # "/source" is inside the chroot envrinonment, as are the commands run above. The significance of the owner/group for tst1/tst2 is that it should not be root, nor portage, at least for demonstrating this bug. I chose man:man for simplicity. I also picked on acct-group/users for simplicity and commonality (should be present on most people's systems). The crux of the matter is that _BOTH_ the current directory _AND_ the parent directory need to be 'x'-cutable by group 'portage'. I demonstrate this with the 'chmod o+x . ..' command. Once that's set, ebuild (and by extension, emerge) works fine. My understanding is that ebuild drops privilege to user 'portage', and that causes the problem, until 'portage' can access the current and parent directory. BTW, this is also solved by 'chgrp portage . ..' instead of the 'chmod ...' I run into this because my /source directory is mounted from my $HOME directory outside the chroot to /source inside the chroot, and I run with 'umask 027'. 'umask 027' masks the 'other' permissions when creating files/directories, so my tst1/tst2 were created with 0750 (as shown above). ANALYSIS: Getting to these directories is not a problem for 'root' inside the chroot, but as soon as ebuild drops privilege to 'portage' and tries a 'getcwd', we get the shell-init issue that many people have seen. Workaround is to run in a directory/parent-directory that has 'x' bit set for 'portage' (directly or indirectly). Could ebuild anticipate this and provide a warning and swallow the 'shell-init ...' output? Probably. Should it? I don't know... Execution continues, and everything seems to work. That's as of today. My bigger concern is what will happen in the future. Given that ebuild/emerge works (and the message is merely confusing/annoying), the getcwd might be just a side-effect, which could probably be by-passed. If the getcwd truly isn't needed, then that could be removed from ebuild, if possible.
