DynamicUsers and read-only /var

[lennart@xxxxxxxxxxxxxx (Lennart Poettering)]

On Mi, 16.05.18 13:29, Antoine Pietri (antoine.pietri1 at gmail.com) wrote:

> Hi,
> 
> Our organization uses a diskless setup to boot hundreds of machines
> using a read-only NFS export of their common rootfs.
> 
> To be able to run services that need to write in /var, we can't just
> have /var as a tmpfs, because it contains files installed by packages
> that are required by some services to run. Our current solution was to
> have /var in read-only, but have a list of directories where some
> services actually write (/var/log, /var/spool/mail, etc) and mount
> them as tmpfs.

Uh, if /var is read-only you kinda void your warranty. I mean, it's
already in the name that /var is "variable", no?

You are fine to make pretty much everything else read-only, but /tmp,
/var and /dev/shm really need to be writable for a normal system to
operate. They don't have to be persistant, but writable they really
should be. If you are this rule, then that's of course OK, but you get
to keep the pieces. This is even documented, very explicitly in
file-hierarchy(7).

I am not sure I grok your reason for making /var read-only
though. Note that today's systems should be mostly fine with /var
being empty at boot, as they ship enough configuration with tmpfiles.d
drop-ins so that what is missing in /var is created as needed early on
boot, and hence /var is sufficiently populated for everything to
work. If you are encounter a package that does not ship the right
tmpfiles.d/ snippets to make empty /var bootups just work, then please
consider working with the respective upstreams to fix that. It's as
easy as shipping one more drop-in file in the rpm/deb, and everybody's
life is easier.

In the unlikely case that some package needs files in /var that are
more than empty dirs/files with the right perms, then you can even
make use of tmpfiles' "factory logic" where it can automatically copy
a set of files from /usr early on, to ensure /var is properly
populated.

> This year, some services like systemd-timesyncd are shipped with
> DynamicUser=yes by default in our distribution (Archlinux), which
> means the above solution no longer works. My understanding is that
> systemd requires a writable /var to be able to symlink the state
> directory the first time it is launched.

Correct.

Lennart

-- 
Lennart Poettering, Red Hat