New: Target file system skeleton permissions hazard

https://bugs.busybox.net/show_bug.cgi?id=7981

Summary: Target file system skeleton permissions hazard
Product: buildroot
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: minor
Priority: P5
Component: Other
AssignedTo: unassigned at buildroot.uclibc.org
ReportedBy: juju at cotds.org
CC: buildroot at uclibc.org
Estimated Hours: 0.0

The content of the file "system/device_table.txt" is a subset of filesystem structure present in "system/skeleton/".

Permissions of entries in the skeleton that are not in the device_table.txt will inherits their permission from the building user environment. Those permissions will mainly depends of the developer's umask at the moment of the git checkout (or tar extraction).

This could lead to some file permissions hazard, especially when the developer's umask is not 0022 AND a user is added to the buildroot target system (with mkusers). Basically, this user account won't be usable if it cannot access to its home directory or binaries.

How to reproduce:
tested with master branch at commit 6202592

cd /var/tmp/
umask 0077
git clone git://git.buildroot.net/buildroot
make qemu_x86_defconfig # Any defconfig will be fine
make
ls -al output/target/

Actual result:
The following target filesystem entries won't be accessible by a user other than root:

/bin
/home
/lib
/media
/mnt
/opt
/proc
/run
/sbin
/sys
/usr
/usr/bin
/usr/lib
/usr/sbin
/var
/var/lib

Expected result:
Default target file system permissions should be stable and usable by a user, unrelated to the build user umask.

I would suggest to add relevant entries to the device_table.txt file. If not possible, a sanity check, a warning or a note in the documentation would be fine.

Thanks.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=7981

--- Comment #1 from Arnout Vandecappelle <[email protected]> 2015-04-01 19:25:09 UTC --- This is a known issue, and a patch series was posted a while ago that should fix it. Could you try it out? If it works out, please add your Tested-by: tag to the series.

For your convenience, I've created a patchwork bundle of this series:
http://patchwork.ozlabs.org/bundle/arnout/umask%20handling/

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=7981

--- Comment #2 from Julien Olivain <[email protected]> 2015-04-02 21:39:04 UTC --- I reviewed and tested successfully the mentioned patches with few defconfigs. It fixes the target rootfs perms in case of less common umask at clone or build time (like 0027 or 0077).

Can you please add the Reviewed-by and Tested-by lines?

Thanks!

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=7981

Thomas Petazzoni <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Thomas Petazzoni <[email protected]> 2015-07-30 10:09:12 UTC --- The umask problem has been fixed by
http://git.buildroot.net/buildroot/commit/Makefile?id=bee5745ccc20be6dbba243b1f8af0d5c522923e8,
http://git.buildroot.net/buildroot/commit/Makefile?id=361d3573f5373618b2c566e250430269dd7200e5
and related commits.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.