Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 389249 - 12.2 Merging/Directories requires PM to do the impossible
Summary: 12.2 Merging/Directories requires PM to do the impossible
Status: CONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-01 22:27 UTC by Michał Górny
Modified: 2011-11-04 15:30 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-11-01 22:27:12 UTC
PMS 12.2 specifies that:

> The owner, group and mode (including set*id and sticky bits) of the directory must be preserved [...]

What if two packages install the same directory with different permissions?

For example, package A installs:

/usr/lib/foo/foo

where /usr/lib/foo is 0755.

Package B installs:

/usr/lib/foo/bar

where /usr/lib/foo is 0700.

Per spec, PM would have to preserve permissions of both directories which is just impossible. The behavior nearest to correct would be erroring out because of non-matching permissions.

I think we either have to specify that packages are actually obligated to share same permissions for each and every directory installed, or decide clearly how to handle such a case.
Comment 1 Ulrich Müller gentoo-dev 2011-11-01 23:59:24 UTC
Are there any ebuilds in the tree that have such conflicting permissions, or is this a hypothetical scenario?
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-11-02 08:30:36 UTC
(In reply to comment #1)
> Are there any ebuilds in the tree that have such conflicting permissions, or is
> this a hypothetical scenario?

Hypothetical. Don't think anyone checks that right now.
Comment 3 Martin Väth 2011-11-02 09:06:27 UTC
Actually, things are "worse" with symlinks:

If the user decided to turn /usr/lib/foo into a symlink
(e.g. in order to move that directory to a different partition for
whatever reason), hell would break loose if merging would "transform"
that symlink into a directory.

My suggestion is to specify that existing directories are not modified
during merging (which is what portage currently seems to be doing).
Comment 4 Ciaran McCreesh 2011-11-02 09:11:19 UTC
PMS is worded so that you never have to turn a directory into a symlink or a symlink into a directory.
Comment 5 Ulrich Müller gentoo-dev 2011-11-04 12:39:58 UTC
(In reply to comment #0)
> > The owner, group and mode (including set*id and sticky bits) of the
> > directory must be preserved [...]

Hm, and that sentence continues:

| [...] except as follows:
| • Any directory owned by the user used to perform the build must become
|   owned by the root user.
| • Any directory whose group is the primary group of the user used to
|   perform the build must have its group be that of the root user.

And there is a similar wording in the section about plain files. It implies that at some point the PM has to do a chown/chgrp root on these files. However, it is not specified when exactly this should be done.

So I wonder if the spec could/should be tightened? Looks like Portage does these owner changes immediately after src_install, is it the same for the other PMs?
Comment 6 Ciaran McCreesh 2011-11-04 15:30:48 UTC
I think it should be saying that it only holds if the directory is newly created.