Bug 674990 – sys-apps/portage-2.3.53-r1 - wrong permissions in build directory

• Product: Portage Development
• Status: UNCONFIRMED ---

[Description Joakim Tjernlund 2019-01-09 13:39:02 UTC]

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.

[Comment 1 Zac Medico 2019-01-09 19:13:18 UTC]

These permissions are intentional. The clean phase is intended to require root privileges if the ebuild previously executed as root.

[Comment 2 Joakim Tjernlund 2019-01-09 20:08:13 UTC]

(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.

[Comment 3 Zac Medico 2019-01-09 20:14:49 UTC]

Yes, it's completely natural for root privileges to be asymmetric in comparison to non-root privileges.

[Comment 4 Joakim Tjernlund 2019-01-09 20:21:12 UTC]

(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?

[Comment 5 Zac Medico 2019-01-09 20:50:20 UTC]

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.

[Comment 6 Joakim Tjernlund 2019-01-09 21:27:06 UTC]

(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) ?

[Comment 7 Zac Medico 2019-01-09 21:45:01 UTC]

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.

[Comment 8 Joakim Tjernlund 2019-01-09 22:12:44 UTC]

(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.