Bug 1416600 - A few folders in /usr are not owner-writable
Summary: A few folders in /usr are not owner-writable
Keywords:
Status: CLOSED DUPLICATE of bug 517575
Alias: None
Product: Fedora Container Images
Classification: Fedora
Component: mirrormanager2-mirrorlist
Version: 25
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Patrick Uiterwijk
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-26 01:13 UTC by Felix Abecassis
Modified: 2018-06-07 13:43 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-27 22:45:37 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 517575 0 low CLOSED Changes for lowering capabilities project 2021-02-22 00:41:40 UTC

Internal Links: 517575

Description Felix Abecassis 2017-01-26 01:13:42 UTC
Description of problem:
Also see: https://github.com/CentOS/sig-cloud-instance-images/issues/67
Some folders are only "r-x" for owner. It's totally fine when you're root, but it creates some headaches when exporting the filesystem somewhere:

$ docker export 247a91b02d2b | tar -xvf - -C /tmp/fedora
[...]
$ touch /tmp/fedora/usr/src/foo # OK
$ touch /tmp/fedora/usr/lib/bar
touch: cannot touch '/tmp/centos7/usr/lib/bar': Permission denied

I know that the Singularity project (containers for HPC: https://github.com/singularityware/singularity) had to resort to workarounds for this issue since you can get a "permission denied" when extracting docker layers on top of each others as a normal user.


Version-Release number of selected component (if applicable):
Docker image fedora:25, but also applies for centos images.
Apparently, a bare metal install has the same behavior though.

How reproducible:
Always


Steps to Reproduce:
$ docker run -ti fedora:25 bash
[root@247a91b02d2b /]# dnf install findutils
[root@247a91b02d2b /]# find /usr -type d -not -perm -u=w -printf "%M\t%p\n"
dr-xr-xr-x      /usr/lib64
dr-xr-xr-x      /usr/lib64/tls
dr-xr-xr-x      /usr/lib64/games
dr-xr-xr-x      /usr/lib64/sse2
dr-xr-xr-x      /usr/lib64/pm-utils
dr-xr-xr-x      /usr/lib64/pm-utils/module.d
dr-xr-xr-x      /usr/lib64/pm-utils/power.d
dr-xr-xr-x      /usr/lib64/pm-utils/sleep.d
dr-xr-xr-x      /usr/lib64/X11
dr-xr-xr-x      /usr/lib
dr-xr-xr-x      /usr/lib/games
dr-xr-xr-x      /usr/lib/sse2
dr-xr-xr-x      /usr/sbin
dr-xr-xr-x      /usr/bin
dr-xr-xr-x      /usr/share/empty



Expected results:
debian and ubuntu images are rwx for all these folders.
Maybe there is a reason behind this, but looking at the list of folders it looks rather arbitrary.

Thank you,

Comment 1 Felix Abecassis 2017-01-26 01:15:06 UTC
For the impact on Singularity, see this comment from one of its maintainer:
https://github.com/CentOS/sig-cloud-instance-images/issues/67#issuecomment-264596653

Comment 2 Felix Abecassis 2017-01-27 18:33:31 UTC
On the original GitHub bug report mentioned in the description, the culprit seems to be the "filesystem" package since CentOS 6:
https://github.com/CentOS/sig-cloud-instance-images/issues/67#issuecomment-275631819

Comment 3 Felix Abecassis 2017-01-27 18:41:05 UTC
Note that this issue also creates complications in the context of user namespaces, see this comment:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1659087/comments/8
Receiving EOVERFLOW when your UID is not part of the user namespace seems to be the new behavior that upstream will follow, setfsuid/setfsgid must be used instead, but when the rootfs has weird permissions like that, you must also enable CAP_DAC_OVERRIDE to make it work.

Comment 4 Colin Walters 2017-01-27 22:45:37 UTC

*** This bug has been marked as a duplicate of bug 517575 ***

Comment 5 Adam Williamson 2017-01-27 23:42:19 UTC
well, this isn't strictly speaking a *dupe*, because that was the bug that actually *requested the change in the first place*; this bug is reporting a problem *caused by* that change. that's why I set See Also, not duplicate. but it's not a big deal.

Comment 6 Michael Shigorin 2017-01-28 06:30:19 UTC
That bug looks like a formal public announcement of a (stupid) thing to do;
the problem created was briefly discussed there as well indeed:
https://bugzilla.redhat.com/show_bug.cgi?id=517575#c2

I've asked Dmitry Levin since and IIRC he didn't see any real security benefit in the change made as well.


Note You need to log in before you can comment on or make changes to this bug.