Bug 7981 - Target file system skeleton permissions hazard
Summary: Target file system skeleton permissions hazard
Status: RESOLVED FIXED
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: PC Linux
: P5 minor
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-31 19:48 UTC by Julien Olivain
Modified: 2015-07-30 10:09 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Olivain 2015-03-31 19:48:45 UTC
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.
Comment 1 Arnout Vandecappelle 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/
Comment 2 Julien Olivain 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?

Reviewed-by: Julien Olivain <juju@cotds.org>
Tested-by: Julien Olivain <juju@cotds.org>

Thanks!