Build icetea as root: ebuild /usr/portage/dev-java/icedtea/icedtea-3.9.0.ebuild install then ls -l /var/tmp/portage/dev-java/icedtea-3.9.0/ total 8 drwxr-xr-x 8 portage portage 257 Jan 4 17:18 ./ drwxrwxr-x 6 portage portage 119 Jan 9 14:25 ../ drwxr-xr-x 2 portage portage 4096 Jan 4 17:18 build-info/ -rw-r--r-- 1 portage portage 0 Jan 4 17:17 .compiled -rw-r--r-- 1 portage portage 0 Jan 4 17:07 .configured drwxr-xr-x 2 root portage 4096 Jan 4 14:53 distdir/ lrwxrwxrwx 1 root root 35 Jan 4 17:07 files -> /usr/portage/dev-java/icedtea/files/ drwxr-xr-x 2 portage portage 6 Jan 4 17:07 homedir/ drwxr-xr-x 4 root root 28 Jan 4 17:17 image/ -rw-r--r-- 1 root root 0 Jan 4 17:18 .installed prwxrwx--- 1 root portage 0 Jan 4 17:18 .ipc_in| prwxrwx--- 1 root portage 0 Jan 4 17:18 .ipc_out| -rw-r--r-- 1 portage portage 0 Jan 4 17:07 .prepared -rw-r--r-- 1 root root 0 Jan 4 14:53 .pretended -rw-r--r-- 1 root root 0 Jan 4 17:07 .setuped drwxr-xr-x 4 portage portage 167 Jan 4 17:18 temp/ -rw-r--r-- 1 portage portage 0 Jan 4 17:07 .unpacked drwx------ 3 portage portage 27 Jan 4 17:07 work/ Here lots of files/dirs are not writeable for portage group. A normal user cannot clean and rebuild in this case.
These permissions are intentional. The clean phase is intended to require root privileges if the ebuild previously executed as root.
(In reply to Zac Medico from comment #1) > These permissions are intentional. The clean phase is intended to require > root privileges if the ebuild previously executed as root. But why? Should not a member of portage group be enough? As it, the behaviour is asymetrical: As root I can clean out another users build dir.
Yes, it's completely natural for root privileges to be asymmetric in comparison to non-root privileges.
(In reply to Zac Medico from comment #3) > Yes, it's completely natural for root privileges to be asymmetric in > comparison to non-root privileges. You said: These permissions are intentional. The clean phase is intended to require root privileges if the ebuild previously executed as root. One could read that as "only the user that created the stuff may rm it" but obviously this is not the case. This boils down to my first Q: why is this the intended behaviour? What problem does is solve?
I think we probably should facilitate private per-user PORTAGE_TMPDIR rather than make it easier to interfere with root processes. Anything that allows interference with root processes could be a potential security vulnerability.
(In reply to Zac Medico from comment #5) > I think we probably should facilitate private per-user PORTAGE_TMPDIR rather > than make it easier to interfere with root processes. Anything that allows > interference with root processes could be a potential security vulnerability. But interference is already happening, look at .ipc_in/.ipc_out . Could we at least have read privs for portage on everything(look at work) ?
The work directory permissions are adjustable with the PORTAGE_WORKDIR_MODE variable. (In reply to Joakim Tjernlund from comment #6) > But interference is already happening, look at .ipc_in/.ipc_out . Existence of vulnerabilities is not justification to introduce more vulnerabilities.
(In reply to Zac Medico from comment #7) > The work directory permissions are adjustable with the PORTAGE_WORKDIR_MODE > variable. Thanks, will look at that > > (In reply to Joakim Tjernlund from comment #6) > > But interference is already happening, look at .ipc_in/.ipc_out . > > Existence of vulnerabilities is not justification to introduce more > vulnerabilities. I didn't mean it like so, just that you might want to change privs on these two.