[Buildroot] target rootfs permissions

[Guido Martínez]

Hi all,

On Sat, Oct 25, 2014 at 10:34:54AM +0200, Thomas Petazzoni wrote:
> Dear Guido Martínez,
> 
> On Fri, 24 Oct 2014 16:34:36 -0300, Guido Martínez wrote:
> 
> > I've noticed that when building a rootfs, some of the permissions on the
> > target depend on the users umask (directly and indirectly). This occurs
> > because some files (notably the system skeleton and overlay) are copied
> > with "rsync -a", which copies permissions exactly as they were on the
> > source. The thing is, Git doesn't track file permissions (except for
> > the exec bit) so both of these depend on the users umask at the time of
> > cloning (if there were no posterior changes).
> > 
> > Also, some files are created in BR code with cp/mkdir, which depend on
> > the current umask.
> > 
> > I think this is pretty important, since if we do care about permissions,
> > the target rootfs may not be easily reproducible on other hosts.
> > 
> > For my current project, we do need a specific set of permissions and
> > ownerships for each file in the rootfs. We're trying to isolate the
> > custom application from the rest of the system, and give it the exact
> > privileges it needs. I found that when I build the rootfs (my umask
> > was 0027) the application could not do absolutely anything as / wasn't
> > executable or readable by it. But building on other hosts (with more
> > relaxed umasks) we had a working rootfs.
> > 
> > We accomplished this by adding a custom script that gets called just
> > prior to the image creation, inside of the fakeroot script (thus, it
> > gets called multiple times, but this isn't a big deal for us).
> > 
> > One downside of our approach is that in order to not depend on the
> > previous set of permissions (which could vary), we need to specify the
> > exact mode for each file. So we need to set the sticky bit on /tmp
> > manually, make /etc/shadow not readable and etc, etc, etc.
> > 
> > Permissions alone could (maybe) be fixed by changing BR code to
> > be aware of this issue, and by setting correct permissions on the
> > overlay/skeleton via some script. But ownerships cannot be changed by
> > a non-root user! And, since building as root is a Very Bad Thing (tm),
> > we'd need to resort to fakeroot.
> > 
> > So: has anyone else had this problem?
> > Is it important for someone else?
> > What do you think a mainline solution would look like?
> 
> Thanks for your report. It is indeed a problem that should be fixed.
> The only clean solution that I see is to have the fakeroot script reset
> the permission for all files to a certain sane value (just like we
> already have a 'chown -h -R 0:0' to re-assign all files to the root
> user), and then re-adjust using makedevs the permissions of the needed
> files, such as /tmp, /etc/shadow and so on.
Good to know I'm not crazy! ;)

I have been trying a solution based on running 'chmod -R u=rwX,go=rX'
for the last few days and it seems to work just fine. We're basically
making everything public (exception should go in the device table or in
*_PERMISSIONS) and keeping the executable bits of files that already
have them. This saves the trouble of making packages declare which files
should be executable.

Packages should only declare ownerships, special permissions (like
sticky bits and setuids) and private files (like /etc/sudoers). Most of
them (at least the ones I could find) do exactly this, so I don't think
much breakage should appear (but undoubtedly, some will). I'd go as far
as saying that 644 is the default permissions everyone unconsciously has
in mind.

A build using this change is perfectly reproducible, given one does not
mess with output/target too much (if you set the exec bit on a random
file, it will set).

This change also clears up quite a bit of system/device_table.txt since
most of the permissions declared there are the defaults.

I can submit a proper patch if it sounds reasonable for you guys.

> Since /tmp, /etc/shadow and so on are part of the skeleton, one option
> would be to make the skeleton a real package, so it could declare a
> SKELETON_PERMISSIONS variable to adjust whatever is needed. This is
> quite in line with some discussions we had recently about cleaning up
> the skeleton from init scripts, and possibly making it a proper package.
Right, that would be great, but it wouldn't fix the issue of variability
due to the permissions of the overlay files (hence due to the umask
too), right?

Cheers!
-- 
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar