Re: fuse mount failure when type contains '.'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 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@xxxxxxxxxx>
 http://karelzak.blogspot.com





[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux