[Buildroot] target rootfs permissions

[Guido Martínez]

Hi all,

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 a lot guys!

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