Hi, libICE tries to access /proc/<PID>/uid_map which fails with enabled pid-sandbox. I'll attach the build.log and the output of emerge --info. Note that the FEATURES list at the top of the build.log is obviously not complete. Reproducible: Always
Created attachment 765516 [details] build.log build.log including the sandbox violation
Created attachment 765517 [details] Output of emerge --info libICE sandbox
I think xmlto may be to blame?
Just a guess but are you using firejail? I wonder if the new command -v are picking up firejail stuff in /usr/local or so, and uid_map would be related to USER_NS (firejail[userns]).
(In reply to Sam James from comment #3) > I think xmlto may be to blame? That sounds like a valid assumption. I didn't had time to dig deeper, sorry if I 'blamed' the wrong package. (In reply to Ionen Wolkens from comment #4) > Just a guess but are you using firejail? > > I wonder if the new command -v are picking up firejail stuff in /usr/local > or so, and uid_map would be related to USER_NS (firejail[userns]). No, firejail isn't even installed on the machine that is affected, but with FEATURES="pid-sandbox" enabled. If I disable that I can compile libICE without any further issues.
(In reply to Nils Freydank from comment #5) > (In reply to Sam James from comment #3) > > I think xmlto may be to blame? > That sounds like a valid assumption. I didn't had time to dig deeper, sorry > if I 'blamed' the wrong package. Does it still happen if downgrade to stable xmlto? Would want to rule out the -r8 patch being related. emerge -1 =xmlto-0.0.28-r6 > (In reply to Ionen Wolkens from comment #4) > > Just a guess but are you using firejail? > > > > I wonder if the new command -v are picking up firejail stuff in /usr/local > > or so, and uid_map would be related to USER_NS (firejail[userns]). > No, firejail isn't even installed on the machine that is affected, but with > FEATURES="pid-sandbox" enabled. If I disable that I can compile libICE > without any further issues. I see, I guess it's possible it's coming from some regular command xmlto is using then (not that I have any other ideas right now, still can't reproduce with pid-sandbox).
Hi everyone, I identified more affected packages, all of them are affected by both r6 and r8 of xmlto, so I assume the patchset is not the cause. As it indeed looks more related to xmlto than libICE I'll rename the topic of this bug aswell. Searching for packages depending on xmlto I used 'equery d xmlto'. Interstingly libICE wasn't on that list - it has no *DEPEND on xmlto and even '--disable-docs' explictly set in src_configure(). As I don't know yet how that is related to the sandbox issue I'll only note it here and file no separate bug yet. From the list I ignored packages with doc in IUSE as it's disabled on my system. Further I found only three packages that all run into the same sandbox violation: =x11-misc/xdg-utils-1.1.3_p20200220-r5::gentoo =x11-libs/libXtst-1.2.3-r2::gentoo (and libICE which is not in the list below) Note that the whole issue is not necessarily new. I'm not entirely sure when exactly I did enable FEATURES="pid-sandbox" - 'ls' says I touched the file in /etc/portage/make.conf/ last time on 2022-02-14 though. Here is list of some possibly affected packages, i.e. the mentioned output of 'equery d xmlto': * These packages depend on xmlto: app-admin/system-config-printer-1.5.16 (>=app-text/xmlto-0.0.22) app-text/dvisvgm-2.13 (app-text/xmlto) app-text/opensp-1.5.2-r7 (doc ? app-text/xmlto) dev-libs/wayland-1.20.0 (doc ? app-text/xmlto) dev-util/perf-5.15-r1 (doc ? app-text/xmlto) dev-vcs/git-2.35.1 (doc ? app-text/xmlto) media-gfx/zbar-0.23.1 (app-text/xmlto) media-sound/alsa-utils-1.2.6 (doc ? app-text/xmlto) net-firewall/conntrack-tools-1.4.6-r1 (doc ? app-text/xmlto) net-libs/zeromq-4.3.4-r1 (doc ? app-text/xmlto) net-misc/freerdp-2.5.0_p39 (doc ? app-text/xmlto) sys-apps/accountsservice-22.07.5 (doc ? app-text/xmlto) sys-apps/dbus-1.12.20-r4 (app-text/xmlto) sys-apps/portage-3.0.30-r1 (doc ? app-text/xmlto) sys-fs/btrfs-progs-5.16.2 (app-text/xmlto) x11-libs/libSM-1.2.3-r1 (app-text/xmlto) x11-libs/libX11-1.7.3 (app-text/xmlto) x11-libs/libXScrnSaver-1.2.3 (app-text/xmlto) x11-libs/libXau-1.0.9-r1 (app-text/xmlto) x11-libs/libXaw-1.0.14 (app-text/xmlto) x11-libs/libXcomposite-0.4.5 (app-text/xmlto) x11-libs/libXdmcp-1.1.3-r1 (app-text/xmlto) x11-libs/libXext-1.3.4 (app-text/xmlto) x11-libs/libXfixes-6.0.0 (app-text/xmlto) x11-libs/libXfont2-2.0.5 (app-text/xmlto) x11-libs/libXi-1.8 (app-text/xmlto) x11-libs/libXinerama-1.1.4-r1 (app-text/xmlto) x11-libs/libXmu-1.1.3 (app-text/xmlto) x11-libs/libXres-1.2.1 (app-text/xmlto) x11-libs/libXt-1.2.1 (app-text/xmlto) x11-libs/libXtst-1.2.3-r2 (app-text/xmlto) x11-libs/libXv-1.0.11-r2 (app-text/xmlto) x11-libs/libXxf86vm-1.1.4-r2 (app-text/xmlto) x11-libs/libxcb-1.14 (app-text/xmlto) x11-libs/xtrans-1.4.0 (app-text/xmlto) x11-misc/shared-mime-info-2.1 (app-text/xmlto) x11-misc/xdg-utils-1.1.3_p20200220-r5 (>=app-text/xmlto-0.0.28-r3[text(+)])
The build log seems to indicate this is being triggered by portage's own python script "pid-ns-init". This script is responsible for setting up the PID sandbox and establishing the uid map. It obviously needs access to /proc/self/uid_map. F: open_wr S: deny P: /proc/1472/uid_map A: /proc/1472/uid_map R: /proc/1472/uid_map C: /usr/bin/python3.9 /usr/lib/portage/python3.9/pid-ns-init 250 250 250 18 0,1,2 /usr/bin/sandbox [x11-libs/libICE-1.0.10-r1] sandbox /usr/lib/portage/python3.9/ebuild.sh configure My best guess is that you are running emerge itself inside a sandbox instance, which is obviously not supported.
(In reply to Mike Gilbert from comment #8) > ... > My best guess is that you are running emerge itself inside a sandbox > instance, which is obviously not supported. Not that I'm aware off. I have no firejail nor Apparmor nor SELinux even installed on this machine. I remounted /proc with hidepid=0 and removed bubblewrap temporarily for testing, too. After I asked in IRC in #gentoo-de another user couldn't reproduce it (and I guess you all can't either), so it looks like an issue on my system after all. Feel free to ignore this bug or close it as invalid until I find out what happens ;-) PS: I dropped a note on the blocked bug 833863 - this one should definetly not block the stabilization anymore.
Right, I think you're the only one experiencing this issue. Please do report back if you figure out what's happening.
