Ok, so I noticed that libtool was relinking a shared library. What caught my notice was that it was doing so as root, and had somehow escaped the "portage" uid sandbox. I went on #gentoo and asked about it, and got a discussion about something wrong with libtool usage. I'm not sure what the exact bug is. Reproducible: Always Actual Results: emerge strayed outside the sandbox and built stuff as root Expected Results: stay as portage
Created attachment 406280 [details] chatlog on #gentoo that said this was a bug
Created attachment 406282 [details] build log
Created attachment 406284 [details] emerge --info
Also, this seems weird: I typed ctrl-z on the command line to suspend the emerge...but there's still an ld process from the merge running!
[18:46:57] <AStorm> Shentino: yes, it's broken, calls eautoreconf without elibtoolize [18:47:56] <AStorm> apparently the automatic patches don't work for webkit-gtk [18:48:09] <AStorm> since it's regenerating, it's weird that it is not using autotools-utils already [18:48:16] * kahrl_ (~kahrl@dslb-094-220-151-165.094.220.pools.vodafone-ip.de) has joined [18:49:34] * kal0pr has quit (Ping timeout: 248 seconds) [18:50:19] <AStorm> hmm, this is potentially hard, I'd file it as a bug - mention it is relinking [18:50:27] * Debesis has quit (Ping timeout: 276 seconds) [18:51:06] * kahrl has quit (Ping timeout: 276 seconds) [18:51:27] <Shentino> also...I used ctrl-z to suspend the build...and the ld is still running :)
...relinking isn't a bug here - compiling during install phase is. I wonder if dolt is the problem here...(OK, so I'm biased against it)(it's in Source/autotools/SetupLibtool.m4). If it wasn't for the time building it takes... What needs to figured out first is if that compile is triggered by make dependencies or within libtool itself.
Are you sure? Libtool was linking, not compiling...unless your definition of compiling includes linking.
Per the build.log it seems it's relinking (at install time)
And, in that case, I don't see the bug here (Well, at least, that relinking is seen on a lot of other packages too :/)
I disagree. It was compiling as root and that's not secure. It's not supposed to be compiling or linking as any UID other than portage if I have sandboxing enabled.
I don't see in what part it's being run as root outside sandbox/portage control
src_compile is sandboxed
It's not visible in the logs. I only noticed because I was running top at the time on another terminal.
Maybe portage people will know if this behavior is normal or not
The src_install function always runs as root because it needs to set the UID/GID of files which can only be done by root. See bug 566614 for a plan to allow it to run as an unprivileged user.
(In reply to shentino from comment #10) > It was compiling as root and that's not secure. Even though it runs as root, the src_install function still runs in a sandbox when FEATURES=sandbox is enabled. So it's not totally unsafe. > It's not supposed to be compiling or linking as any UID other than portage > if I have sandboxing enabled. Well, if it compiles or links in the src_install function, then it's going to be doing it as root.
Aye, I understand. File UID/GID can only be determined during installation. But my question is whether or not it should be compiling/linking during src_install in the first place. It being done as root just made the frosting a bit more radioactive.
Thanks Zac, this is invalid then @shentino, about complaints against linking at install time, that is an upstream issue and you should report it directly to them... anyway this version is long time ago obsolete and will go away as soon as possible, then, please ensure the latest version is also affected by this (also the build system was changed completely)
