fuse mount failure when type contains '.'

fuse mount failure when type contains '.'

[John Rinehart]

[-- Attachment #1.1: Type: text/plain, Size: 2183 bytes --]

`util-linux` seems to fail to handle a use case that users like me seem to
be hitting with some frequency. The issue is around
https://github.com/util-linux/util-linux/blob/86b6684e7a215a0608bd130371bd7b3faae67aca/libmount/src/context.c#L2115-L2121
and seems rooted in the fact that `util-linux` operates on `type` where
type is always of the form <a>.<b> but where <b> is apparently assumed to
not contain Unicode U+002E (ASCII 2E): '.' ("dotless"). I say it "appears
to assume" this since the logic which appears to remove the subtype does so
by using `strrchr`, which addresses only the last period in the `helper`
string. If the `subtype`, itself, has a U+002E character then this won't
remove the subtype.

As an example, if `helper` looks like
`path/name.type./subtype/path/with/a.period` then the modified `helper`
after `strrchr` will look like `path/name.type./subtype/path/with/a`
instead of the apparently-intended `path/name.type`.

This crops up for users like me because  I use NixOS which is a store-based
Linux operating system using paths like:
```
$ readlink -f $(which s3fs)

/nix/store/xwbx0fbg65ml2qjl86p9p2w58kghqn8r-s3fs-fuse-1.94/bin/s3fs
```
(So, paths like `/nix/store/<hash>-<name>-<version>/bin/<cmd>`). `version`
is usually a dot-delimited string like `1.23`.

I've generated a patch which seems to ameliorate this behavior. It's
attached (sorry if attachments are not the way to go with this mailing
list, specifically, or mailing lists, generally - this is my first time
submitting a patch to a mailing list). The logic is simple, but it
basically iterates through all possible substrings according to the number
of U+002E characters in the `type` string. It's a more generic form of the
logic already present, but it's a little heavy-handed. Happy with any and
all changes which preserve the apparently-corrected behavior.

Please let me know if I should make any changes or if a change like this
won't be accepted for some reason or if I'm misunderstanding the
problem/solution.

Thank you!

Cf.
1. https://discourse.nixos.org/t/how-to-setup-s3fs-mount/6283/5
2. https://github.com/NixOS/nixpkgs/issues/46529#issuecomment-655536831

-- John Rinehart

[-- Attachment #1.2: Type: text/html, Size: 2920 bytes --]

[-- Attachment #2: util-linux.patch --]
[-- Type: text/x-patch, Size: 980 bytes --]

diff --git a/libmount/src/context.c b/libmount/src/context.c
index d38e3671f..411f98f3f 100644
--- a/libmount/src/context.c
+++ b/libmount/src/context.c
@@ -2097,6 +2097,11 @@ int mnt_context_prepare_helper(struct libmnt_context *cxt, const char *name,
 	if (!ns_old)
 		return -MNT_ERR_NAMESPACE;
 
+	/* Record number of '.' in `type` so we can try a few things later. */
+	int dot_count = 0;
+	for (int i=0; type[i]; i++)
+		dot_count += (type[i] == '.');
+
 	/* Ignore errors when search in $PATH and do not modify @rc
 	 */
 	path = strtok_r(search_path, ":", &p);
@@ -2112,8 +2117,8 @@ int mnt_context_prepare_helper(struct libmnt_context *cxt, const char *name,
 			continue;
 
 		found = mnt_is_path(helper);
-		if (!found && strchr(type, '.')) {
-			/* If type ends with ".subtype" try without it */
+		/* If type contains '.' then try without them. */
+		for (int cnt = dot_count; !found && cnt; --cnt) {
 			char *hs = strrchr(helper, '.');
 			if (hs)
 				*hs = '\0';

Re: fuse mount failure when type contains '.'

[Karel Zak]

 Hi John,

On Thu, Aug 01, 2024 at 11:16:30AM GMT, John Rinehart wrote:
> `util-linux` seems to fail to handle a use case that users like me seem to
> be hitting with some frequency. The issue is around
> https://github.com/util-linux/util-linux/blob/86b6684e7a215a0608bd130371bd7b3faae67aca/libmount/src/context.c#L2115-L2121
> and seems rooted in the fact that `util-linux` operates on `type` where
> type is always of the form <a>.<b> but where <b> is apparently assumed to
> not contain Unicode U+002E (ASCII 2E): '.' ("dotless"). I say it "appears
> to assume" this since the logic which appears to remove the subtype does so
> by using `strrchr`, which addresses only the last period in the `helper`
> string. If the `subtype`, itself, has a U+002E character then this won't
> remove the subtype.
> 
> As an example, if `helper` looks like
> `path/name.type./subtype/path/with/a.period` then the modified `helper`
> after `strrchr` will look like `path/name.type./subtype/path/with/a`
> instead of the apparently-intended `path/name.type`.

the convention for filesystem names is (was):

    <type>[.<subtype>]

For example, for the "mount" helper, it is:

    /path/mount.<type>[.<subtype>]

I believe it is acceptable for the "path" to contain dots (or any
other characters). The important thing is the last segment of the path
(e.g. /mount.<type>[.<subtype>]). We should not be concerned with
anything else besides the last segment.

It is strange to assume that <subtype> can also contain path-like
segments and dots. It seems like someone may want to use <subtype> to
encode additional information ...

Miklos (CC:), what is your opinion? Is it correct to assume that <subtype>
is whatever?

    Karel


> This crops up for users like me because  I use NixOS which is a store-based
> Linux operating system using paths like:
> ```
> $ readlink -f $(which s3fs)
> 
> /nix/store/xwbx0fbg65ml2qjl86p9p2w58kghqn8r-s3fs-fuse-1.94/bin/s3fs
> ```
> (So, paths like `/nix/store/<hash>-<name>-<version>/bin/<cmd>`). `version`
> is usually a dot-delimited string like `1.23`.
> 
> I've generated a patch which seems to ameliorate this behavior. It's
> attached (sorry if attachments are not the way to go with this mailing
> list, specifically, or mailing lists, generally - this is my first time
> submitting a patch to a mailing list). The logic is simple, but it
> basically iterates through all possible substrings according to the number
> of U+002E characters in the `type` string. It's a more generic form of the
> logic already present, but it's a little heavy-handed. Happy with any and
> all changes which preserve the apparently-corrected behavior.
> 
> Please let me know if I should make any changes or if a change like this
> won't be accepted for some reason or if I'm misunderstanding the
> problem/solution.
> 
> Thank you!
> 
> Cf.
> 1. https://discourse.nixos.org/t/how-to-setup-s3fs-mount/6283/5
> 2. https://github.com/NixOS/nixpkgs/issues/46529#issuecomment-655536831
> 
> -- John Rinehart



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

Re: fuse mount failure when type contains '.'

[John Rinehart]

>  Hi John,

Hi Karel (and Miklos, CCed) 👋!

> On Thu, Aug 01, 2024 at 11:16:30AM GMT, John Rinehart wrote:
> > `util-linux` seems to fail to handle a use case that users like me seem to
> > be hitting with some frequency. The issue is around
> > https://github.com/util-linux/util-linux/blob/86b6684e7a215a0608bd130371bd7b3faae67aca/libmount/src/context.c#L2115-L2121
> > and seems rooted in the fact that `util-linux` operates on `type` where
> > type is always of the form <a>.<b> but where <b> is apparently assumed to
> > not contain Unicode U+002E (ASCII 2E): '.' ("dotless"). I say it "appears
> > to assume" this since the logic which appears to remove the subtype does so
> > by using `strrchr`, which addresses only the last period in the `helper`
> > string. If the `subtype`, itself, has a U+002E character then this won't
> > remove the subtype.
> >
> > As an example, if `helper` looks like
> > `path/name.type./subtype/path/with/a.period` then the modified `helper`
> > after `strrchr` will look like `path/name.type./subtype/path/with/a`
> > instead of the apparently-intended `path/name.type`.
>
> the convention for filesystem names is (was):
>
>     <type>[.<subtype>]
>
> For example, for the "mount" helper, it is:
>
>     /path/mount.<type>[.<subtype>]
>
> I believe it is acceptable for the "path" to contain dots (or any
> other characters). The important thing is the last segment of the path
> (e.g. /mount.<type>[.<subtype>]). We should not be concerned with
> anything else besides the last segment.
>
> It is strange to assume that <subtype> can also contain path-like
> segments and dots. It seems like someone may want to use <subtype> to
> encode additional information ...

Thanks for your response! If I can restate/augment my case:
`util-linux`'s `mount` implementation will fail to properly delimit
`type` from `subtype` if `subtype` contains `.`. `subtype` is expected
by `mount.fuse` to be an executable compatible with `fuse`. If the
executable isn't reachable from the `$PATH` (which appears to be the
case with the `systemd` mount target auto-generated from my fstab)
then it should be specified absolutely (although this isn't documented
in the man pages for `mount.fuse`). You can understand this logic by
taking a look at
https://github.com/libfuse/libfuse/blob/beff8a8ebe1b413b4b572b93ddca24aaeb904f7a/util/mount.fuse.c#L295-L296
followed by
https://github.com/libfuse/libfuse/blob/beff8a8ebe1b413b4b572b93ddca24aaeb904f7a/util/mount.fuse.c#L432

In the case of my OS's absolute path to the `s3fs` binary (compatible
with and called by `mount.fuse`), it contains a `.` (because of the
version string described previously) which breaks `util-linux`'s
`mount` implementation when it attempts to separate the `type` from
the `subtype`.

`util-linux` hasn't documented any restrictions on character values
contained within `subtype`. So, in consideration of Hyrum's law and in
the spirit of being liberal in what's accepted while conservative in
what's emitted, I'd kindly ask `util-linux` maintainers to support `.`
characters in the `subtype` so that users like me can fearlessly
specify absolute paths to FUSE binaries in their subtype.


> Miklos (CC:), what is your opinion? Is it correct to assume that <subtype>
> is whatever?
>
>     Karel
>
>
> > This crops up for users like me because  I use NixOS which is a store-based
> > Linux operating system using paths like:
> > ```
> > $ readlink -f $(which s3fs)
> >
> > /nix/store/xwbx0fbg65ml2qjl86p9p2w58kghqn8r-s3fs-fuse-1.94/bin/s3fs
> > ```
> > (So, paths like `/nix/store/<hash>-<name>-<version>/bin/<cmd>`). `version`
> > is usually a dot-delimited string like `1.23`.
> >
> > I've generated a patch which seems to ameliorate this behavior. It's
> > attached (sorry if attachments are not the way to go with this mailing
> > list, specifically, or mailing lists, generally - this is my first time
> > submitting a patch to a mailing list). The logic is simple, but it
> > basically iterates through all possible substrings according to the number
> > of U+002E characters in the `type` string. It's a more generic form of the
> > logic already present, but it's a little heavy-handed. Happy with any and
> > all changes which preserve the apparently-corrected behavior.
> >
> > Please let me know if I should make any changes or if a change like this
> > won't be accepted for some reason or if I'm misunderstanding the
> > problem/solution.
> >
> > Thank you!
> >
> > Cf.
> > 1. https://discourse.nixos.org/t/how-to-setup-s3fs-mount/6283/5
> > 2. https://github.com/NixOS/nixpkgs/issues/46529#issuecomment-655536831
> >
> > -- John Rinehart
>
>
>
> --
>  Karel Zak  <kzak@redhat.com>
>  http://karelzak.blogspot.com
>

Re: fuse mount failure when type contains '.'

[Miklos Szeredi]

On Mon, 5 Aug 2024 at 11:49, Karel Zak <kzak@redhat.com> wrote:
>
>
>  Hi John,
>
> On Thu, Aug 01, 2024 at 11:16:30AM GMT, John Rinehart wrote:
> > `util-linux` seems to fail to handle a use case that users like me seem to
> > be hitting with some frequency. The issue is around
> > https://github.com/util-linux/util-linux/blob/86b6684e7a215a0608bd130371bd7b3faae67aca/libmount/src/context.c#L2115-L2121
> > and seems rooted in the fact that `util-linux` operates on `type` where
> > type is always of the form <a>.<b> but where <b> is apparently assumed to
> > not contain Unicode U+002E (ASCII 2E): '.' ("dotless"). I say it "appears
> > to assume" this since the logic which appears to remove the subtype does so
> > by using `strrchr`, which addresses only the last period in the `helper`
> > string. If the `subtype`, itself, has a U+002E character then this won't
> > remove the subtype.
> >
> > As an example, if `helper` looks like
> > `path/name.type./subtype/path/with/a.period` then the modified `helper`
> > after `strrchr` will look like `path/name.type./subtype/path/with/a`
> > instead of the apparently-intended `path/name.type`.
>
> the convention for filesystem names is (was):
>
>     <type>[.<subtype>]
>
> For example, for the "mount" helper, it is:
>
>     /path/mount.<type>[.<subtype>]
>
> I believe it is acceptable for the "path" to contain dots (or any
> other characters). The important thing is the last segment of the path
> (e.g. /mount.<type>[.<subtype>]). We should not be concerned with
> anything else besides the last segment.
>
> It is strange to assume that <subtype> can also contain path-like
> segments and dots. It seems like someone may want to use <subtype> to
> encode additional information ...
>
> Miklos (CC:), what is your opinion? Is it correct to assume that <subtype>
> is whatever?

We can assume that subtype is just [a-zA-Z0-9_]*, I think.

Thanks,
Miklos



>
>     Karel
>
>
> > This crops up for users like me because  I use NixOS which is a store-based
> > Linux operating system using paths like:
> > ```
> > $ readlink -f $(which s3fs)
> >
> > /nix/store/xwbx0fbg65ml2qjl86p9p2w58kghqn8r-s3fs-fuse-1.94/bin/s3fs
> > ```
> > (So, paths like `/nix/store/<hash>-<name>-<version>/bin/<cmd>`). `version`
> > is usually a dot-delimited string like `1.23`.
> >
> > I've generated a patch which seems to ameliorate this behavior. It's
> > attached (sorry if attachments are not the way to go with this mailing
> > list, specifically, or mailing lists, generally - this is my first time
> > submitting a patch to a mailing list). The logic is simple, but it
> > basically iterates through all possible substrings according to the number
> > of U+002E characters in the `type` string. It's a more generic form of the
> > logic already present, but it's a little heavy-handed. Happy with any and
> > all changes which preserve the apparently-corrected behavior.
> >
> > Please let me know if I should make any changes or if a change like this
> > won't be accepted for some reason or if I'm misunderstanding the
> > problem/solution.
> >
> > Thank you!
> >
> > Cf.
> > 1. https://discourse.nixos.org/t/how-to-setup-s3fs-mount/6283/5
> > 2. https://github.com/NixOS/nixpkgs/issues/46529#issuecomment-655536831
> >
> > -- John Rinehart
>
>
>
> --
>  Karel Zak  <kzak@redhat.com>
>  http://karelzak.blogspot.com
>

Re: fuse mount failure when type contains '.'

[John Rinehart]

Thanks for your response.

But, hold up. I demonstrated a(n apparently) valid use case, shared
links where other people have hit this problem over the years, and
proposed an implementation accommodating it (which I'm using in a
patched/forked version of `util-linux`, currently). Since the
requested change would allow for subtypes to include `.` in addition
to [a-zA-Z0-9_]* I don't see a theoretical restriction (even if the
implementation as proposed is unacceptable as-is based on style or
unforeseen edge cases). Users want to use `.` in subtypes, it's
backward-compatible, it doesn't violate any documentation/guarantee
(as far as I can tell) and a working solution has been provided.
What's the rationale for prohibiting this use case?

Thank you.

On Thu, Aug 22, 2024, 07:09 Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Mon, 5 Aug 2024 at 11:49, Karel Zak <kzak@redhat.com> wrote:
> >
> >
> >  Hi John,
> >
> > On Thu, Aug 01, 2024 at 11:16:30AM GMT, John Rinehart wrote:
> > > `util-linux` seems to fail to handle a use case that users like me seem to
> > > be hitting with some frequency. The issue is around
> > > https://github.com/util-linux/util-linux/blob/86b6684e7a215a0608bd130371bd7b3faae67aca/libmount/src/context.c#L2115-L2121
> > > and seems rooted in the fact that `util-linux` operates on `type` where
> > > type is always of the form <a>.<b> but where <b> is apparently assumed to
> > > not contain Unicode U+002E (ASCII 2E): '.' ("dotless"). I say it "appears
> > > to assume" this since the logic which appears to remove the subtype does so
> > > by using `strrchr`, which addresses only the last period in the `helper`
> > > string. If the `subtype`, itself, has a U+002E character then this won't
> > > remove the subtype.
> > >
> > > As an example, if `helper` looks like
> > > `path/name.type./subtype/path/with/a.period` then the modified `helper`
> > > after `strrchr` will look like `path/name.type./subtype/path/with/a`
> > > instead of the apparently-intended `path/name.type`.
> >
> > the convention for filesystem names is (was):
> >
> >     <type>[.<subtype>]
> >
> > For example, for the "mount" helper, it is:
> >
> >     /path/mount.<type>[.<subtype>]
> >
> > I believe it is acceptable for the "path" to contain dots (or any
> > other characters). The important thing is the last segment of the path
> > (e.g. /mount.<type>[.<subtype>]). We should not be concerned with
> > anything else besides the last segment.
> >
> > It is strange to assume that <subtype> can also contain path-like
> > segments and dots. It seems like someone may want to use <subtype> to
> > encode additional information ...
> >
> > Miklos (CC:), what is your opinion? Is it correct to assume that <subtype>
> > is whatever?
>
> We can assume that subtype is just [a-zA-Z0-9_]*, I think.
>
> Thanks,
> Miklos
>
>
>
> >
> >     Karel
> >
> >
> > > This crops up for users like me because  I use NixOS which is a store-based
> > > Linux operating system using paths like:
> > > ```
> > > $ readlink -f $(which s3fs)
> > >
> > > /nix/store/xwbx0fbg65ml2qjl86p9p2w58kghqn8r-s3fs-fuse-1.94/bin/s3fs
> > > ```
> > > (So, paths like `/nix/store/<hash>-<name>-<version>/bin/<cmd>`). `version`
> > > is usually a dot-delimited string like `1.23`.
> > >
> > > I've generated a patch which seems to ameliorate this behavior. It's
> > > attached (sorry if attachments are not the way to go with this mailing
> > > list, specifically, or mailing lists, generally - this is my first time
> > > submitting a patch to a mailing list). The logic is simple, but it
> > > basically iterates through all possible substrings according to the number
> > > of U+002E characters in the `type` string. It's a more generic form of the
> > > logic already present, but it's a little heavy-handed. Happy with any and
> > > all changes which preserve the apparently-corrected behavior.
> > >
> > > Please let me know if I should make any changes or if a change like this
> > > won't be accepted for some reason or if I'm misunderstanding the
> > > problem/solution.
> > >
> > > Thank you!
> > >
> > > Cf.
> > > 1. https://discourse.nixos.org/t/how-to-setup-s3fs-mount/6283/5
> > > 2. https://github.com/NixOS/nixpkgs/issues/46529#issuecomment-655536831
> > >
> > > -- John Rinehart
> >
> >
> >
> > --
> >  Karel Zak  <kzak@redhat.com>
> >  http://karelzak.blogspot.com
> >