Re: [RFC] refactor mnt_fstype_is_pseudofs()?

[Karel Zak <kzak@redhat.com>]

On Fri, Feb 01, 2019 at 12:07:12AM +0100, Stanislav Brabec wrote:
> Hi.
> 
> I got a but report about a dumpfs FUSE filesystem reporting bad mount output.
> 
> The same problem affects other pseudo file systems not listed in mnt_fstype_is_pseudofs():
> # mount | grep encfs
> encfs on /Encrypted type fuse.encfs (rw,nosuid,nodev,relatime,user_id=10027,group_id=100,default_permissions)
> # mkdir encfs
> # mount | grep encfs
> /root/encfs on /Encrypted type fuse.encfs (rw,nosuid,nodev,relatime,user_id=10027,group_id=100,default_permissions)
> ^^^^^^^^^^^
> 
> Debugging shows two reasons why it happens:
> 1) encfs is not listed in mnt_fstype_is_pseudofs()
> 2) mnt_resolve_path() calls canonicalize_path_and_cache() on the kernel output, which makes only a little sense

Where? It should be easy to check by mnt_fs_is_kernel().

> Currently I am aware of three file systems affected at least (i. e. not listed): gvfs (subtype was renamed from gvfs-fuse-daemon to gvfsd-fuse), encfs, dumpfs.
> 
> Easy fix would be adding all of them to the list. But probably much more exists.

It would be nice to have such easy bugfix, so we can backport it to
old version etc. :-)

> More complex would allow to add fuse.*. But it is not correct, because FUSE can be a regular file system based on block device (e. g. fuse ntfs). Yes, such reports "fuseblk" as a default. But still, it can be changed.
> 
> That is why I started thinking about the better fix than adding these three to the list:
> 
> If the column 10 (mount source) of a particular line of /proc/<pid>/mountinfo does not start by "/", then it is a pseudofs. Actually, it could be generalized:

I'm not sure if we always use mnt_fs_is_pseudofs() in situation when
mount source path is available. The libmnt_fs is also able to hold
info about LABEL=foo, etc.

It seems we need to keep mnt_fstype_is_pseudofs() and change
mnt_fs_is_pseudofs() to your suggestion with fallback to
mnt_fstype_is_pseudofs().

> - If it does not contain "/" (or maybe another character) at all, it is a pseudofs.
> - If it contains "/" (or maybe another character), but it does not start by it, it is a network file system.
> - If it starts by "/", it is a regular file system.
> 
> Before implementing, I want to make a wider discussion, whether it could work.
> 
> I talked with a kernel developers, and he told that there is no
> solution "correct by principle". Filesystem developer can provide
> virtually anything as a source. But it could work in most cases.
> 
> What do you think about such change?

If we will keep the fstype lists in the code than we can use it as
the first attempt, if the name is not in the list than use your
heuristic.

> And additionally: Does canonicalization of the kernel output make
> any sense? If not, it could be skipped for commands like a bare
> "mount". (But I am not sure how complicated it would be.)

It depends, kernel canonicalizes mountpoint, but if I good remember it
does not touch source, so if the source is for example symlink and
it's not mounted by mount(8) than whatever is in the kernel output:

 # ln -s /dev/sdc /dev/foo
 # simple_mount /dev/foo /mnt/test ext4 1

 # grep foo /proc/self/mountinfo 
 624 94 8:32 / /mnt/test ro,relatime shared:323 - ext4 /dev/foo ro,stripe=512
                                                       ^^^^^^^^
mount(8) always canonicalizes everything, but in case you use use
something else to call mount(2) syscall...

For mount, findmnt, etc. we make sure (for years) that all is canonical as
it is only way how to keep things consistent. Not sure if we want to
change it and introduce regression in scripts where people use "mount |
grep <devname>".

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com