* [PATCH] mount: Do not call mnt_pretty_path() on net file systems. @ 2019-02-05 22:57 Stanislav Brabec 2019-02-05 23:07 ` Stanislav Brabec 0 siblings, 1 reply; 6+ messages in thread From: Stanislav Brabec @ 2019-02-05 22:57 UTC (permalink / raw) To: util-linux Calling mnt_pretty_path() on network file systems can cause mangling of the output: nfs.example.com:/home on /home type nfs4 ... /root/nfs.example.com:/home on /home type nfs4 ... Signed-off-by: Stanislav Brabec <sbrabec@suse.cz> --- sys-utils/mount.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys-utils/mount.c b/sys-utils/mount.c index f4a387b8a..b91d4779a 100644 --- a/sys-utils/mount.c +++ b/sys-utils/mount.c @@ -143,7 +143,7 @@ static void print_all(struct libmnt_context *cxt, char *pattern, int show_label) if (type && pattern && !mnt_match_fstype(type, pattern)) continue; - if (!mnt_fs_is_pseudofs(fs)) + if (!mnt_fs_is_pseudofs(fs) && !mnt_fs_is_netfs(fs)) xsrc = mnt_pretty_path(src, cache); printf ("%s on ", xsrc ? xsrc : src); safe_fputs(mnt_fs_get_target(fs)); -- 2.20.1 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH] mount: Do not call mnt_pretty_path() on net file systems. 2019-02-05 22:57 [PATCH] mount: Do not call mnt_pretty_path() on net file systems Stanislav Brabec @ 2019-02-05 23:07 ` Stanislav Brabec 2019-02-06 10:58 ` Karel Zak 0 siblings, 1 reply; 6+ messages in thread From: Stanislav Brabec @ 2019-02-05 23:07 UTC (permalink / raw) To: util-linux Calling mnt_pretty_path() on network file systems can cause mangling of the output: root# mount | grep nfs nfs.example.com:/home on /home type nfs4 ... root# mkdir -p nfs.example.com:/home root# mount | grep nfs /root/nfs.example.com:/home on /home type nfs4 ... Signed-off-by: Stanislav Brabec <sbrabec@suse.cz> --- sys-utils/mount.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys-utils/mount.c b/sys-utils/mount.c index f4a387b8a..b91d4779a 100644 --- a/sys-utils/mount.c +++ b/sys-utils/mount.c @@ -143,7 +143,7 @@ static void print_all(struct libmnt_context *cxt, char *pattern, int show_label) if (type && pattern && !mnt_match_fstype(type, pattern)) continue; - if (!mnt_fs_is_pseudofs(fs)) + if (!mnt_fs_is_pseudofs(fs) && !mnt_fs_is_netfs(fs)) xsrc = mnt_pretty_path(src, cache); printf ("%s on ", xsrc ? xsrc : src); safe_fputs(mnt_fs_get_target(fs)); -- 2.20.1 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] mount: Do not call mnt_pretty_path() on net file systems. 2019-02-05 23:07 ` Stanislav Brabec @ 2019-02-06 10:58 ` Karel Zak 2019-02-19 15:50 ` Stanislav Brabec 0 siblings, 1 reply; 6+ messages in thread From: Karel Zak @ 2019-02-06 10:58 UTC (permalink / raw) To: Stanislav Brabec; +Cc: util-linux 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(). Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mount: Do not call mnt_pretty_path() on net file systems. 2019-02-06 10:58 ` Karel Zak @ 2019-02-19 15:50 ` Stanislav Brabec 2019-02-22 10:26 ` Karel Zak 0 siblings, 1 reply; 6+ messages in thread From: Stanislav Brabec @ 2019-02-19 15:50 UTC (permalink / raw) To: Karel Zak; +Cc: util-linux 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. 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 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 encfs: can be detected by type, source cannot be detected encfs on /local/Encrypted type fuse.encfs (rw,nosuid,nodev,relatime,user_id=10027,group_id=100,default_permissions) 397 540 0:84 / /local/Encrypted rw,nosuid,nodev,relatime - fuse.encfs encfs rw,user_id=10027,group_id=100,default_permissions gvfs: can be detected by type, source cannot be detected gvfsd-fuse on /run/user/10027/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=10027,group_id=100) 562 536 0:48 / /run/user/10027/gvfs rw,nosuid,nodev,relatime master:291 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=10027,group_id=100 archivemount: can be detected by type, source cannot be detected archivemount on /home/sbrabec/T type fuse.archivemount (rw,nosuid,nodev,relatime,user_id=10027,group_id=100) 376 539 0:65 / /home/sbrabec/T rw,nosuid,nodev,relatime - fuse.archivemount archivemount rw,user_id=10027,group_id=100 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mount: Do not call mnt_pretty_path() on net file systems. 2019-02-19 15:50 ` Stanislav Brabec @ 2019-02-22 10:26 ` Karel Zak 2019-02-22 18:39 ` Stanislav Brabec 0 siblings, 1 reply; 6+ messages in thread From: Karel Zak @ 2019-02-22 10:26 UTC (permalink / raw) To: Stanislav Brabec; +Cc: util-linux 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. > 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? > > 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 ;-) Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mount: Do not call mnt_pretty_path() on net file systems. 2019-02-22 10:26 ` Karel Zak @ 2019-02-22 18:39 ` Stanislav Brabec 0 siblings, 0 replies; 6+ messages in thread From: Stanislav Brabec @ 2019-02-22 18:39 UTC (permalink / raw) To: Karel Zak; +Cc: util-linux 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@suse.com 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-02-22 18:39 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-05 22:57 [PATCH] mount: Do not call mnt_pretty_path() on net file systems Stanislav Brabec 2019-02-05 23:07 ` Stanislav Brabec 2019-02-06 10:58 ` Karel Zak 2019-02-19 15:50 ` Stanislav Brabec 2019-02-22 10:26 ` Karel Zak 2019-02-22 18:39 ` Stanislav Brabec
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).