[yocto] How handle files needing updates in read-only filesystem

[Ulf Samuelsson]

Thanks,

We want most of /etc to be read-only for security reasons,
and the overlayfs will make the whole of /etc writeable.

I tried mount —bind /etc/timezone /persistent/etc/timezone, and it complained that they were not directories. Bind mounting /etc again will make all of /etc writeable.

Symlinking to /persistent is fine, so the question is what an acceptable method is to have a simple way of ensuring that a certain file is converted to that symlink.



Best Regards,
Ulf Samuelsson
+46 722 427 437

10 juni 2018 kl. 01:36 skrev Peter Kjellerstedt <peter.kjellerstedt at axis.com>:

>> -----Original Message-----
>> From: yocto-bounces at yoctoproject.org [mailto:yocto-
>> bounces at yoctoproject.org] On Behalf Of Ulf Samuelsson
>> Sent: den 9 juni 2018 11:51
>> To: yocto at yoctoproject.org
>> Subject: [yocto] How handle files needing updates in read-only
>> filesystem
>> 
>> We have a rootfs which is read-only.
>> For files that needs to be updated, like "/etc/localtime"
>> we will create a symbolic link to a partition (/persistent) which
>> is retained between rootfs image updates.
>> 
>> /etc/localtime -> /persistent/etc/localtime
>> 
>> The original recipe will generate the real /etc/localtime of course.
>> 
>> To support the file beeing updated, the following needs to be done in a
>> rootfs postprocess.
>> 
>> mv   /etc/localtime /update/etc/localtime
>> ln   -sf /persistent/etc/localtime /etc/localtime
>> install -m 0644 /update/etc/localtime /persistent/etc/localtime
>> chown <user>:<group> /persistent/etc/localtime
>> 
>> The last two commands needs to be executed on the running system,
>> since /persistent is not part of the rootfs.
>> 
>> To ensure that the file can be updated is an ad-hoc activity for each
>> affected file. It would be better if there was a class where you
>> declare
>> a file to be writeable, and then a post process
>> would move the file to /update (or similar) and create a symbolic link
>> 
>> SETTINGS ?= "/persistent"
>> =============================
>> inherit writeable
>> 
>> WRITEABLE = "/etc/localtime"
>> =============================
>> 
>> This would generate the first two commands for each listed file.
>> 
>> mv   /etc/localtime /update/etc/localtime
>> ln   -sf ${SETTINGS}/etc/localtime /etc/localtime
>> 
>> The file would also be added to a file indicating that it may need
>> to be copied to the ${SETTINGS}
>> 
>> Is it a good solution to modify "populate_volatiles.sh"
>> to support a second file parameter for the f (file) command
>> in the /etc/default/volatiles file?
>> 
>> Today the file create command looks like:
>> f <mode> <uid> <gid> <filename> <ignored>
>> 
>> An idea would be to have the following syntax:
>> f <mode> <uid> <gid> <filename> <source>
>> 
>> If <source> is a valid filepath, then copy this file to <filename>
>> If <source> is not a valid filepath, create <filename> using "touch"
>> 
>> This would break any build which has a "funny" volatiles file.
>> Otherwise a script called populate_persistent.sh could be
>> created with such an extension.
>> 
>> Comments?
>> 
>> BR
>> Ulf Samuelsson
> 
> Since a  lot of files in /etc typically need to be writable, one way to 
> handle this is by using an overlayfs for /etc. That is what we do and 
> it works very well.
> 
> An alternative, more along your suggestion, is to use bind mounts. The 
> advantage of using a bind mount instead of a symbolic link is that it 
> will look as a normal file.
> 
> You should look into the volatile-binds recipe and the VOLATILE_BINDS 
> variable. It is used to handle directories that need to be writable. 
> It will create systemd service files that copies the non-volatile 
> directory to the volatile directory (if it does not already exists), 
> and the bind mounts it back. 
> 
> I am not sure volatile-binds works out-of-the-box for files, but I 
> believe it does. If not, it should not be too hard to modify it so 
> that it can handle files as well.
> 
> //Peter
>