target rootfs permissions

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?

Dear Guido Mart?nez,

Quoted 37 lines · Guido Mart?nez

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.

Quoted 3 lines

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.

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.

Hi all,

Quoted 11 lines · Thomas Petazzoni

Dear Guido Mart?nez,

Quoted 7 lines · Guido Mart?nez

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).

Quoted 6 lines

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.

Quoted 5 lines

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!

On 30/10/14 14:15, Guido Mart?nez wrote:
[snip]

Quoted 7 lines

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.

Quoted 6 lines

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.

There is one problem with this solution: it means that for each package, we
have to make sure that we find and apply all the special permissions it requires. And that's something that can only be discovered at runtime. It's much better if we could rely on the package's build infrastructure to do the right thing.

So what we really want to do is to clear the umask. I found [1] which suggests
to do

SHELL = /bin/bash --noprofile -c 'umask 000; eval "$$2"' --

Alternatively, we could also reset the umask in the places where it's relevant,
i.e. where rsync and cp are used - but that's a bit complicated an risky - we might forget something.

For the skeleton and overlay, the umask is not the issue, it's just the fact
that we preserve permissions. That could easily be solved by using --chmod=u=rwX,go=rX for rsync.