portable profile broken file bind mount (/etc/resolv.conf)

[Peter Morrow <pemorrow@xxxxxxxxxxxxxxxxxxx>]

Hi,

I ran into an issue (v239 custom yocto based distro, though the code is the same with latest releases) where a portable service ends up with a broken file
bind mount since the file is deleted and recreated on the host. This behaviour
is expected for a file based bind mount, the issue is that the default
portable profile makes use of this pattern when it might be better to bind
mount the parent directory. This would allow changes to be reflected from the
host to the portable service.

Taking a look at the default portable profile
src/portable/profile/default/service.conf we see:

BindReadOnlyPaths=/etc/resolv.conf

/etc/resolv.conf is symlink to /etc/resolv-conf.systemd which is a
symlink to /run/systemd/resolve/resolv.conf.

The issue comes via src/resolve/resolved.c:

        /* Write finish default resolv.conf to avoid a dangling symlink */
        (void) manager_write_resolv_conf(m);

The above writes out /run/systemd/resolve/resolv.conf, though obviously
any time manager_write_resolv_conf() is called then
/run/systemd/resolve/resolv.conf is deleted since the file update does
not happen in place:

manager_write_resolv_conf():

if (rename(temp_path_uplink, PRIVATE_UPLINK_RESOLV_CONF) < 0)
                r = log_error_errno(errno, "Failed to move new %s into
place: %m", PRIVATE_UPLINK_RESOLV_CONF);


This means if the DNS servers are updated after the portable service is
started and the bind mount has completed then we still see the old
version of /run/systemd/resolve/resolv.conf.

I was thinking that it would be better if the default portable profile
instead had this line in it:

BindReadOnlyPaths=/run/systemd/resolve/

So that if /run/systemd/resolve/resolv.conf is deleted and recreated
then the portable service will see the new version of the file.  This
only works since the same heirarchy of symlinks exists in the portable
service image. Is this an OK solution or is it fragile or something
else? I am happy to send a PR to change this if it seems like a workable
solution.

Thanks!
Peter.
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel