[systemd-devel] [PATCH] path_is_mount_point: handle false positive on some fs

[Didier Roche]

Le 10/03/2015 16:53, Lennart Poettering a écrit :
> On Mon, 09.03.15 11:27, Didier Roche (didrocks at ubuntu.com) wrote:
>
>> However, some file systems (seems overlayfs at least) would report a
>> major(st_dev) as 0 on directories and not on files. The current
>> path_is_mount_point() fallback logic would thus reports that every files is
>> a mount point. The enclosed patch introduces a second fallback to read
>> /proc/mounts, and ensures there is no shadowing by later mounting of parent
>> directories. This slower path is only used when the 2 first methods failed
>> to determine with assurance if the path is a mount point or not.
> Humppf, I am not convinced this is really a good idea.
>
> I mean, we use name_to_handle_at() precisely for the reason that we
> don't want to parse /proc/self/mountinfo, since that is really
> cumbersome if you want to do it properly, given that mounts can
> obstruct other mounts and symlink/realpath complexity and stuff.
>
> Note that the st_dev thing is the traditional way to detect whether
> one crosses a file system boundary. It's used for this by tools like
> cp, find, .... We slightly enhance this by using name_to_handle_at(),
> so that we can also detect bind mounts from file systems onto
> themselves. Now, if overlayfs breaks the same file system logic of all
> other tools, I am not convinced that systemd should not be broken by
> it too.. It sounds surprising that we should work around this in
> systemd, but not in all other tools.
>
> Or to turn this around: instead of patching systemd the better idea
> would probably be to teach overlayfs name_to_handle_at() support, so
> that there's a way to detect the mount id from such a file system in a
> safe way.
>
> Hmm, where precisely did you run into problems with this?

The context is bug 
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1411140, where 
systemd-machine-id-commit unit is entering in failed state (the binary 
handles gracefully the fact that it can't unmount the file) on a default 
ubuntu live system (which is a squashfs/overlayfs system).

This means that a live starts in degraded mode when booted with systemd 
(mostly a cosmetic issue for sure, but we would rather avoid it). Seeing 
that the logic to check if a path is a mount point already had a 
fallback (the traditional way), I thought another one would be 
acceptable, but I understand that you were ok with the first one as it's 
the general way tools are detecting that case. I thought as Ryan told 
that glib was going to a similar approach that this fallback would be a 
little bit more considered as standard…

I agree that the best way would be to get the kernel fixed for this, I 
talked to our kernel team and it doesn't seem we would gain traction on 
having name_to_handle_at() support on overlayfs, so quite stuck on this 
for now. Maybe there is a better option?

Cheers,
Didier