Dne 22. 02. 19 v 11:26 Karel Zak napsal(a): > On Tue, Feb 19, 2019 at 04:50:26PM +0100, Stanislav Brabec wrote: >> Dne 06. 02. 19 v 11:58 Karel Zak napsal(a): >>> On Wed, Feb 06, 2019 at 12:07:54AM +0100, Stanislav Brabec wrote: >>>> sys-utils/mount.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> Applied, thanks! >>> >>> Please, send also updates for the mnt_fstype_is_pseudofs(). >>> >> >> I started to inspect file systems available in SUSE, and I found >> that there is an another category of file systems: File systems that >> have a source (so they are not pseudo file systems), but information >> provided by the kernel is not sufficient to check whether a >> particular source is already mounted. >> >> Some of them are completely undetectable (both source and FS type >> provide generic information only), some are detectable by source, >> but not by FS type, some are detectable by FS type, but source match >> cannot be used. >> >> For these file systems, mount(8) cannot guarantee that the correct >> volume is mounted. Only some guesses are possible. > > The question is how critical is it for us... maybe all we need is to > document mount(8) limitations for these cases. I identified four problems of mount caused by incorrect implementations of FUSE drivers: 1. If a file system that does not provide its source is not listed as virtualfs or netfs, then is affected by the canonicalization problem (output of mount can be affected by contents of the working directory). 2. Inconsistency between mount output and mount input. It's hard to guess what needs to be added to fstab. For example, in case of lower mentioned curlftpfs, it is possible to mount it from the fstab. But the arguments are different than the mount output: ftp.suse.com /home/sbrabec/T fuse.curlftpfs defaults 0 0 (Note that file system has to be be "fuse.curlftpfs", not plain "fuse"). 3. We enter into a problem with "mount -a": # mount -a # mount -a fuse: mountpoint is not empty fuse: if you are sure this is safe, use the 'nonempty' mount option The inconsistency causes inability to detect that it is the same file system. 4. Inconsistency between provided source and accepted source: If we try fstab: curlftpfs#ftp://ftp.suse.com/ /home/sbrabec/T fuse.curlftpfs defaults 0 0 we will get: # mount -a Error connecting to ftp: Could not resolve host: curlftpfs It is a fault of the curlftpfs itself. mount properly passes argument to mount.fuse and it to curlftpfs binary. But it does not understand it. (Note that it cannot be fixed by adding "fuse.curlftpfs" to mnt_fstype_is_netfs() or mnt_fstype_is_pseudofs().) So I would consider such fuse implementations as semi-broken, and we should at least issue a warning when a file system provides dumb strings. >> Maybe it should warn about it, or it should refuse such file systems in the fstab. >> >> >> Examples of undetectable FUSE file systems: >> >> xdg-document-portal is completely undetectable; it can be ran once per UID >> /dev/fuse on /run/user/10027/doc type fuse (rw,nosuid,nodev,relatime,user_id=10027,group_id=100) >> 376 536 0:65 / /run/user/10027/doc rw,nosuid,nodev,relatime - fuse /dev/fuse rw,user_id=10027,group_id=100 > > No subtype ? How FUSE driver redirects it to the right code? No subtype. I am not sure, how FUSE works internally, but these file systems are handled by a separate user space task. So probably no redirect is needed. >> >> curlftpfs undetectable by type, detectable by source >> curlftpfs#ftp://ftp.suse.com/ on /home/sbrabec/T type fuse (rw,nosuid,nodev,relatime,user_id=10027,group_id=100) >> 544 510 0:47 / /sys/fs/fuse/connections rw,relatime master:282 - fusectl fusectl rw > > "subtype#" is deprecated; I guess fuse.curlftpfs has to work ;-) curlftpfs# is not a subtype. It is a source. Type is "fuse", subtype is not set. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@xxxxxxxx Křižíkova 148/34 (Corso IIa) tel: +420 284 084 060 186 00 Praha 8-Karlín fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
