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,
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
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
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.
*** This bug has been marked as a duplicate of bug 517575 ***
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.
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.