[systemd-devel] mount units and symlinks

[Lennart Poettering]

On Mon, 30.06.14 12:23, Colin Walters (walters at verbum.org) wrote:

> Hi, we were trying to update systemd to git master in gnome-continuous,
> and hit an issue with mount points that are symlinks.
> 
> It's pretty easy to reproduce:
> 
> mkdir /mnt/a
> ln -s a /mnt/b
> cat > /etc/systemd/system/mnt-b.mount << EOF
> [Mount]
> What=tmpfs
> Where=/mnt/b
> Type=tmpfs
> Options=mode=1777,strictatime
> EOF
> systemctl daemon-reload
> systemctl start mnt-b.mount
> 
> # Notice that we can see this mount via *both* units:
> systemctl status mnt-a.mount
> systemctl status mnt-b.mount
> 
> # Now let's do an unrelated mount:
> 
> mkdir /mnt/unrelated
> mount --bind /mnt/unrelated /mnt/unrelated
> 
> systemctl status mnt-a.mount
> systemctl status mnt-b.mount
> # Notice mnt-b died
> 
> This happens because on any mountpoint change, we mark all mounts as
> dead, and only reload the ones we see.  But the kernel resolved the b ->
> a symlink at mount time, so it doesn't exist from the kernel's
> perspective.
> 
> In gnome-continuous this breaks the /tmp -> /sysroot/tmp link; which I
> could work around in a different way perhaps, but it would be nice if
> systemd had better semantics for mount points that are symlinks.

Why would you create such a symlink? This sounds wrong. /tmp should
generally be a tmpfs these days, why would you link that?

BTW, I have now prepped a man page that codifies the assumptions and
suggestions systemd makes on the file system hierarchy:

http://www.freedesktop.org/software/systemd/man/file-hierarchy.html

> What would the right thing here be?  Should e.g. systemd follow the
> links and create two units from mount points that contain symlinks,
> explicitly having the source reflect destination?

I am pretty sure we should simply prohibit mounts on existing
symlinks. Sounds unnecessary and pretty dangerous to me. Not entirely
sure though how we can effectively prohibit this, given that there is no
lmount(), i.e. a mount() that refuses following mount points. We could
implement this in a racy way by stat()ing first, which might be good
enough (after all this requires priv), but of course not pretty...

Lennart

-- 
Lennart Poettering, Red Hat