fuse-sshfs — SSH Filesystem related discussion

Re: [sshfs] [SECURITY] SSHFS 3.7.6 release fixing 2 vulnerabilities

[Nikolaus R. <nik...@ra...>]

On Sun, 31 May 2026, at 17:02, Abhinav Agarwal wrote:
> Hi Nikolaus,
> 
> Thanks for reviewing the advisories. In both cases the issue is a trust boundary, and I'll try to be precise about what is and isn't sshfs's fault.
> CVE-2026-47187 (symlink targets)
> For a local symlink you're right: whoever planted it already had local write access, so "don't follow untrusted symlinks" is just Unix. The difference here is who controls the target - the remote SFTP server, which in this threat model is untrusted (the case being mounting servers you don't administer: shared boxes, sftp dropboxes, a compromised host).

I still do not understand how this is different from, for example, root accessing a symlink in a user's home directory.

Putting it differently, you should never follow symlinks when writing into a path that you do not trust. This is already the case locally, and it also applies when accessing a network mount (like SSHFS).

My best guess is that you're trying to make SSHFS mounts more secure than local directories. Maybe that's a useful feature in some situations, but the absence of such an (unexpected) feature is not a security vulnerability any more that my front door has a "security vulnerability" because it doesn't protect me from walking out without an umbrella and getting wet if it rains. It's not the job of a front door to protect me from rain, and it's not the job of a filesystem to protect the user from symlinks.

> When you mount a server at /mnt, the reasonable expectation is that client operations aren't redirected to arbitrary client-local paths by server-controlled metadata. 

I disagree that this is a reasonable expectation. If you don't want to follow symlinks (because you don't trust them), you shouldn't use file system operations that automatically follow symlinks. 

> The honest counterpoint is that NFS and CIFS reflect server symlinks the same way and were never CVE'd for it. What I'd point to is that sshfs already had an option that partially addressed this class for absolute symlinks - transform_symlinks rewrote absolute targets - but it never covered relative "../" escapes. Once a partial mitigation is defeated by a path it didn't anticipate, the residual is reasonable to treat as an sshfs-side 
> [...]

The crucial difference is that "transform_symlinks" is a convenience feature that needs to be explicitly enabled, it is not a security feature. I have no objections to making transform_symlinks more powerful but please don't call it a security vulnerability - and don't enable it by default.

(The documentation of the new "contain_symlinks" option says that it rejects access to any symlink target containing ".." - this will cover a huge number of legitimate use-cases and isn't even needed, since only targets that resolve to outside the mountpoint are risky by your definition).

> hardening gap, not just generic Unix symlink advice. rsync draws the same line: --safe-links exists precisely to 

The crucial difference is that rsync is not providing a filesystem but writing to the local filesystem, which users may want to continue to trust.

> CVE-2026-48711 (argument injection)
> You're right that this is a non-issue when a user runs sshfs directly and controls the command line. The case I'd point to is composition: any service that maps an untrusted source string onto an sshfs invocation, 

...is buggy and has a security vulnerability. That's not SSHFS fault.


By all means, I do not object to any of the changes. You found a bug in the argument parsing (though it requires intent to trigger), and you added a feature to block access to some symlinks. These are real improvements, but there is no need to sell them as security vulnerabilities. The claim that not using "contain_symlinks" should only be used with "fully trusted" servers is misleading (you should still think twice about connecting to an untrusted server even if you enable contain_symlinks, and not using contain_symlinks simply means that you should not trust the directory structure any more than you trust the server).


Best,
-Nikolaus

Re: [sshfs] [SECURITY] SSHFS 3.7.6 release fixing 2 vulnerabilities

[Abhinav A. <abh...@gm...>]

Hi Nikolaus,

Thanks for reviewing the advisories. In both cases the issue is a trust
boundary, and I'll try to be precise about what is and isn't sshfs's fault.

CVE-2026-47187 (symlink targets)

For a local symlink you're right: whoever planted it already had local
write access, so "don't follow untrusted symlinks" is just Unix. The
difference here is who controls the target - the remote SFTP server, which
in this threat model is untrusted (the case being mounting servers you
don't administer: shared boxes, sftp dropboxes, a compromised host).

When you mount a server at /mnt, the reasonable expectation is that client
operations aren't redirected to arbitrary client-local paths by
server-controlled metadata. A server-supplied symlink with an absolute
target ($HOME/.ssh/config) or a relative escape
(../../../tmp/client-secret) breaks that: it is reflected into the local
VFS, and ordinary client operations - cp, an editor, a backup job - resolve
it against the *client* filesystem. The server picks the path, so it gains
a local read (the user's own tool reads whatever the target resolves to on
the client - say $HOME/.ssh/config, within the client user's own
permissions - and writes that data back over the mount, i.e. to the server
via SFTP; sshfs itself never opens the file) or a local write (server bytes
land on a server-chosen local path) - through the user's own commands, with
no prior local foothold beyond inducing the user to mount and interact with
the server, and no client-side code execution.

The honest counterpoint is that NFS and CIFS reflect server symlinks the
same way and were never CVE'd for it. What I'd point to is that sshfs
already had an option that partially addressed this class for absolute
symlinks - transform_symlinks rewrote absolute targets - but it never
covered relative "../" escapes. Once a partial mitigation is defeated by a
path it didn't anticipate, the residual is reasonable to treat as an
sshfs-side hardening gap, not just generic Unix symlink advice. rsync draws
the same line: --safe-links exists precisely to drop absolute or
tree-escaping targets, and a CVE was assigned for a gap in that guard
(CVE-2024-12088). contain_symlinks closes the gap by default;
no_contain_symlinks restores the old behavior for trusted servers.


CVE-2026-48711 (argument injection)

You're right that this is a non-issue when a user runs sshfs directly and
controls the command line. The case I'd point to is composition: any
service that maps an untrusted source string onto an sshfs invocation,
meaning to grant only "host:path". I don't have a published exploit against
a specific product to point to - the argument is that the parse owes the
same end-of-options guarantee git's connect path does.

sshfs defines and parses that "host:path" format, so I'd argue sshfs owns
that argv boundary: a value accepted in the host slot shouldn't be able to
become an ssh option. With [-oProxyCommand=CMD]:/path, find_base_path()
strips the brackets into a "-"-leading hostname that older sshfs passed to
ssh with no end-of-options guard - so the host value became an ssh option.
That is the parse failing to contain the host field, not solely the
caller's fault for passing a documented format. It's the same class git
fixed in 2017 (CVE-2017-1000117; Mercurial and Subversion shipped analogous
reject-"-" hardening), and more recently Cockpit (CVE-2026-4631) - in each
case the fix went into the component that builds the ssh argv and owns the
host-field parse boundary, not into ssh itself. Callers still need to
validate their inputs - but sshfs owns the argv it builds, the same way git
owns the one it hands to ssh.


A couple of corrections on our side:

- The advisories should say the server "induces" local I/O, not that it
writes local files directly - that wording overreached.
- On a second look the Critical/9.3 on the symlink issue is too high. The
attacker is still the remote server and the harm needs the user to run
local tooling (UI:R).

Happy to fold the threat models into both advisories so they don't lean on
the changelog.

Best
Abhinav


On Sun, May 31, 2026 at 5:08 AM Nikolaus Rath <nik...@ra...> wrote:

> Hi Haoxi,
>
> On Sun, 31 May 2026, at 12:03, H Tan wrote:
>
> Hi Nikolaus,
>
> So with the first vuln, my understanding is that when you mount sshfs to a
> sub dir, you trust the server to ONLY be able to read/write data inside
> that sub directory.
>
>
> I assume with "the server" you mean the local SSHFS process?
>
> In that case I agree, and SSHFS already guarantees that (since it's only
> ever sending data to the SSH server, which by definition can only write
> inside the mounted directory).
>
> The vuln is a malicious server (e.g. a unix shared box where an attacker
> has root) can read and write outside that directory.
>
>
> But then talking about a "malicious server" doesn't make sense. So I guess
> with "server" you mean the remote ssh server? In that case you do not need
> to "trust" it, it can only write to remote filesystems by construction
> (since the sshfs "client" is not executing any instructions, it just sends
> instructions to the server).
>
> That's exactly the kind of threat model sshfs needs to defend against from
> a client side perspective if mounting a shared server, especially now that
> Linux LPE bugs drop so frequently.
>
>
> I do not understand this sentence (nor the threat model).
>
> The second one is the ability to inject commands where the hostname is
> expected. You're right that it's a non-issue if the user is running sshfs
> on the command line. It'll only be an issue if sshfs is a component in a
> server-side integration, such as a router CGI interface allowing users to
> remote mount with controlled arguments like hostname, user pass and proxy.
> It's only an issue if sshfs is used in a context that doesn't assume the
> user can execute arbitrary ssh commands, but not a real issue for normal
> usage.
>
>
> In that case, I'd say that any "vulnerability" is in the CGI interface,
> not in SSHFS.
>
> Best,
> -Nikolaus
>
>
>
>
>
> Hope that helps.
>
>
> On Sun, 31 May 2026 at 8:19 pm, Nikolaus Rath <nik...@ra...> wrote:
>
>
> Hi,
>
> Could you provide a bit more detail about these vulnerabilities? Having
> read the Github announcement, neither of these sound like vulnerabilities
> to me:
>
> - https://github.com/libfuse/sshfs/security/advisories/GHSA-pjv6-2c3f-r357 seems
> to boil down to "don't write data into untrusted symlinks" - which is a
> general property of Unix filesystem semantics, not a bug in SSHFS.  If I
> create a symlink from ~/data/logs.txt to /etc/passwd, and can get another
> user (say root) to write into this file, then I have "tricked" root into
> writing to /etc/passwd. Why does this become a security vulnerability if
> ~/data happens to be an SSHFS mountpoint rather than a local directory tree?
>
>
> - https://github.com/libfuse/sshfs/security/advisories/GHSA-mm85-q63v-4476 seems
> to boil down to "if you can call SSHFS with arbitrary arguments, you can
> call SSH with arbitrary arguments". Not sure why this is a security
> vulnerability either, since both processes run on the same machine as the
> same user.
>
> Am I missing something?
>
> Best,
> -Nikolaus
>
> On Sat, 30 May 2026, at 00:49, H Tan wrote:
>
>
> Hi all,
>
> We have found 2 vulnerabilities in SSHFS (1 Critical, 1 High) and have
> patched them in the latest release 3.7.6.
> https://github.com/libfuse/sshfs/releases/tag/sshfs-3.7.6
>
> For distro maintainers please test and downstream this release at your
> earliest convenience. Both are client side vulnerabilities, one of them
> requires a rogue server for exploitation.
>
> See the below changelog:
>
>
>    - - Added new maintainer: abhinavagarwal07 Abhinav Agarwal
>    - - Fixed critical vulnerability CVE-2026-47187
>    <https://github.com/libfuse/sshfs/security/advisories/GHSA-pjv6-2c3f-r357>
>    - Symlink Escape: Rogue SFTP Server to Local File Read/Write), credit to
>    abhinavagarwal07
>    - - New -o contain_symlinks and -o no_contain_symlinks to control
>    symlink containment behavior
>    - - Fixed high severity vulnerability CVE-2026-48711
>    <https://github.com/libfuse/sshfs/security/advisories/GHSA-mm85-q63v-4476>
>    - Improper Neutralization of Argument Delimiters in a Command ('Argument
>    Injection'), credit to abhinavagarwal07
>    - - Fixed null-deref warning in tokenize_on_space, promote
>    strict-warnings to required
>    - - Added a number of tests in CI, including rename, chmod, fsync,
>    statvfs values, error paths, option coverage
>    - - Fixed malformed SFTP reply handling
>    - - Hardened Github Actions workflow with SHA pins, permissions,
>    timeouts, and dependabot
>
>
> Thanks for all your efforts and continued support of SSHFS.
>
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
>

Re: [sshfs] [SECURITY] SSHFS 3.7.6 release fixing 2 vulnerabilities

[Nikolaus R. <nik...@ra...>]

Hi Haoxi,

On Sun, 31 May 2026, at 12:03, H Tan wrote:
> Hi Nikolaus,
> 
> So with the first vuln, my understanding is that when you mount sshfs to a sub dir, you trust the server to ONLY be able to read/write data inside that sub directory.

I assume with "the server" you mean the local SSHFS process? 

In that case I agree, and SSHFS already guarantees that (since it's only ever sending data to the SSH server, which by definition can only write inside the mounted directory).

> The vuln is a malicious server (e.g. a unix shared box where an attacker has root) can read and write outside that directory. 

But then talking about a "malicious server" doesn't make sense. So I guess with "server" you mean the remote ssh server? In that case you do not need to "trust" it, it can only write to remote filesystems by construction (since the sshfs "client" is not executing any instructions, it just sends instructions to the server).

> That's exactly the kind of threat model sshfs needs to defend against from a client side perspective if mounting a shared server, especially now that Linux LPE bugs drop so frequently.

I do not understand this sentence (nor the threat model).

> The second one is the ability to inject commands where the hostname is expected. You're right that it's a non-issue if the user is running sshfs on the command line. It'll only be an issue if sshfs is a component in a server-side integration, such as a router CGI interface allowing users to remote mount with controlled arguments like hostname, user pass and proxy. 
> It's only an issue if sshfs is used in a context that doesn't assume the user can execute arbitrary ssh commands, but not a real issue for normal usage.

In that case, I'd say that any "vulnerability" is in the CGI interface, not in SSHFS. 

Best,
-Nikolaus




> 
> Hope that helps.
> 
> 
> On Sun, 31 May 2026 at 8:19 pm, Nikolaus Rath <nik...@ra...> wrote:
>> __
>> Hi,
>> 
>> Could you provide a bit more detail about these vulnerabilities? Having read the Github announcement, neither of these sound like vulnerabilities to me:
>> 
>> - https://github.com/libfuse/sshfs/security/advisories/GHSA-pjv6-2c3f-r357 seems to boil down to "don't write data into untrusted symlinks" - which is a general property of Unix filesystem semantics, not a bug in SSHFS.  If I create a symlink from ~/data/logs.txt to /etc/passwd, and can get another user (say root) to write into this file, then I have "tricked" root into writing to /etc/passwd. Why does this become a security vulnerability if ~/data happens to be an SSHFS mountpoint rather than a local directory tree?
>> 
>> 
>> - https://github.com/libfuse/sshfs/security/advisories/GHSA-mm85-q63v-4476 seems to boil down to "if you can call SSHFS with arbitrary arguments, you can call SSH with arbitrary arguments". Not sure why this is a security vulnerability either, since both processes run on the same machine as the same user. 
>> 
>> Am I missing something?
>> 
>> Best,
>> -Nikolaus
>> 
>> On Sat, 30 May 2026, at 00:49, H Tan wrote:
>>> 
>>> Hi all,
>>> 
>>> We have found 2 vulnerabilities in SSHFS (1 Critical, 1 High) and have patched them in the latest release 3.7.6. https://github.com/libfuse/sshfs/releases/tag/sshfs-3.7.6
>>> 
>>> For distro maintainers please test and downstream this release at your earliest convenience. Both are client side vulnerabilities, one of them requires a rogue server for exploitation.
>>> 
>>> See the below changelog:
>>> 
>>>  • - Added new maintainer: abhinavagarwal07 Abhinav Agarwal
>>>  • - Fixed critical vulnerability CVE-2026-47187 <https://github.com/libfuse/sshfs/security/advisories/GHSA-pjv6-2c3f-r357> - Symlink Escape: Rogue SFTP Server to Local File Read/Write), credit to abhinavagarwal07
>>>  • - New -o contain_symlinks and -o no_contain_symlinks to control symlink containment behavior
>>>  • - Fixed high severity vulnerability CVE-2026-48711 <https://github.com/libfuse/sshfs/security/advisories/GHSA-mm85-q63v-4476> - Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'), credit to abhinavagarwal07
>>>  • - Fixed null-deref warning in tokenize_on_space, promote strict-warnings to required
>>>  • - Added a number of tests in CI, including rename, chmod, fsync, statvfs values, error paths, option coverage
>>>  • - Fixed malformed SFTP reply handling
>>>  • - Hardened Github Actions workflow with SHA pins, permissions, timeouts, and dependabot
>>> 
>>> Thanks for all your efforts and continued support of SSHFS.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> fuse-sshfs mailing list
>>> fus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
>>> 
>> 
>> _______________________________________________
>> fuse-sshfs mailing list
>> fus...@li...
>> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs

Re: [sshfs] [SECURITY] SSHFS 3.7.6 release fixing 2 vulnerabilities

[H T. <hao...@gm...>]

Hi Nikolaus,

So with the first vuln, my understanding is that when you mount sshfs to a
sub dir, you trust the server to ONLY be able to read/write data inside
that sub directory. The vuln is a malicious server (e.g. a unix shared box
where an attacker has root) can read and write outside that directory.
That's exactly the kind of threat model sshfs needs to defend against from
a client side perspective if mounting a shared server, especially now that
Linux LPE bugs drop so frequently.

The second one is the ability to inject commands where the hostname is
expected. You're right that it's a non-issue if the user is running sshfs
on the command line. It'll only be an issue if sshfs is a component in a
server-side integration, such as a router CGI interface allowing users to
remote mount with controlled arguments like hostname, user pass and proxy.
It's only an issue if sshfs is used in a context that doesn't assume the
user can execute arbitrary ssh commands, but not a real issue for normal
usage.

Hope that helps.


On Sun, 31 May 2026 at 8:19 pm, Nikolaus Rath <nik...@ra...> wrote:

> Hi,
>
> Could you provide a bit more detail about these vulnerabilities? Having
> read the Github announcement, neither of these sound like vulnerabilities
> to me:
>
> - https://github.com/libfuse/sshfs/security/advisories/GHSA-pjv6-2c3f-r357 seems
> to boil down to "don't write data into untrusted symlinks" - which is a
> general property of Unix filesystem semantics, not a bug in SSHFS.  If I
> create a symlink from ~/data/logs.txt to /etc/passwd, and can get another
> user (say root) to write into this file, then I have "tricked" root into
> writing to /etc/passwd. Why does this become a security vulnerability if
> ~/data happens to be an SSHFS mountpoint rather than a local directory tree?
>
>
> - https://github.com/libfuse/sshfs/security/advisories/GHSA-mm85-q63v-4476 seems
> to boil down to "if you can call SSHFS with arbitrary arguments, you can
> call SSH with arbitrary arguments". Not sure why this is a security
> vulnerability either, since both processes run on the same machine as the
> same user.
>
> Am I missing something?
>
> Best,
> -Nikolaus
>
> On Sat, 30 May 2026, at 00:49, H Tan wrote:
>
> Hi all,
>
> We have found 2 vulnerabilities in SSHFS (1 Critical, 1 High) and have
> patched them in the latest release 3.7.6.
> https://github.com/libfuse/sshfs/releases/tag/sshfs-3.7.6
>
> For distro maintainers please test and downstream this release at your
> earliest convenience. Both are client side vulnerabilities, one of them
> requires a rogue server for exploitation.
>
> See the below changelog:
>
>
>    - - Added new maintainer: abhinavagarwal07 Abhinav Agarwal
>    - - Fixed critical vulnerability CVE-2026-47187
>    <https://github.com/libfuse/sshfs/security/advisories/GHSA-pjv6-2c3f-r357>
>    - Symlink Escape: Rogue SFTP Server to Local File Read/Write), credit to
>    abhinavagarwal07
>    - - New -o contain_symlinks and -o no_contain_symlinks to control
>    symlink containment behavior
>    - - Fixed high severity vulnerability CVE-2026-48711
>    <https://github.com/libfuse/sshfs/security/advisories/GHSA-mm85-q63v-4476>
>    - Improper Neutralization of Argument Delimiters in a Command ('Argument
>    Injection'), credit to abhinavagarwal07
>    - - Fixed null-deref warning in tokenize_on_space, promote
>    strict-warnings to required
>    - - Added a number of tests in CI, including rename, chmod, fsync,
>    statvfs values, error paths, option coverage
>    - - Fixed malformed SFTP reply handling
>    - - Hardened Github Actions workflow with SHA pins, permissions,
>    timeouts, and dependabot
>
>
> Thanks for all your efforts and continued support of SSHFS.
>
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
>

Re: [sshfs] [SECURITY] SSHFS 3.7.6 release fixing 2 vulnerabilities

[Nikolaus R. <nik...@ra...>]

Hi,

Could you provide a bit more detail about these vulnerabilities? Having read the Github announcement, neither of these sound like vulnerabilities to me:

- https://github.com/libfuse/sshfs/security/advisories/GHSA-pjv6-2c3f-r357 seems to boil down to "don't write data into untrusted symlinks" - which is a general property of Unix filesystem semantics, not a bug in SSHFS.  If I create a symlink from ~/data/logs.txt to /etc/passwd, and can get another user (say root) to write into this file, then I have "tricked" root into writing to /etc/passwd. Why does this become a security vulnerability if ~/data happens to be an SSHFS mountpoint rather than a local directory tree?


- https://github.com/libfuse/sshfs/security/advisories/GHSA-mm85-q63v-4476 seems to boil down to "if you can call SSHFS with arbitrary arguments, you can call SSH with arbitrary arguments". Not sure why this is a security vulnerability either, since both processes run on the same machine as the same user. 

Am I missing something?

Best,
-Nikolaus

On Sat, 30 May 2026, at 00:49, H Tan wrote:
> Hi all,
> 
> We have found 2 vulnerabilities in SSHFS (1 Critical, 1 High) and have patched them in the latest release 3.7.6. https://github.com/libfuse/sshfs/releases/tag/sshfs-3.7.6
> 
> For distro maintainers please test and downstream this release at your earliest convenience. Both are client side vulnerabilities, one of them requires a rogue server for exploitation.
> 
> See the below changelog:
> 
>  * - Added new maintainer: abhinavagarwal07 Abhinav Agarwal
>  * - Fixed critical vulnerability CVE-2026-47187 <https://github.com/libfuse/sshfs/security/advisories/GHSA-pjv6-2c3f-r357> - Symlink Escape: Rogue SFTP Server to Local File Read/Write), credit to abhinavagarwal07
>  * - New -o contain_symlinks and -o no_contain_symlinks to control symlink containment behavior
>  * - Fixed high severity vulnerability CVE-2026-48711 <https://github.com/libfuse/sshfs/security/advisories/GHSA-mm85-q63v-4476> - Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'), credit to abhinavagarwal07
>  * - Fixed null-deref warning in tokenize_on_space, promote strict-warnings to required
>  * - Added a number of tests in CI, including rename, chmod, fsync, statvfs values, error paths, option coverage
>  * - Fixed malformed SFTP reply handling
>  * - Hardened Github Actions workflow with SHA pins, permissions, timeouts, and dependabot
> 
> Thanks for all your efforts and continued support of SSHFS.
> 
> 
> 
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
> 

[sshfs] [SECURITY] SSHFS 3.7.6 release fixing 2 vulnerabilities

[H T. <hao...@gm...>]

Hi all,

We have found 2 vulnerabilities in SSHFS (1 Critical, 1 High) and have
patched them in the latest release 3.7.6.
https://github.com/libfuse/sshfs/releases/tag/sshfs-3.7.6

For distro maintainers please test and downstream this release at your
earliest convenience. Both are client side vulnerabilities, one of them
requires a rogue server for exploitation.

See the below changelog:

- - Added new maintainer: abhinavagarwal07 Abhinav Agarwal
- - Fixed critical vulnerability CVE-2026-47187
<https://github.com/libfuse/sshfs/security/advisories/GHSA-pjv6-2c3f-r357>
- Symlink Escape: Rogue SFTP Server to Local File Read/Write), credit to
abhinavagarwal07
- - New -o contain_symlinks and -o no_contain_symlinks to control symlink
containment behavior
- - Fixed high severity vulnerability CVE-2026-48711
<https://github.com/libfuse/sshfs/security/advisories/GHSA-mm85-q63v-4476>
- Improper Neutralization of Argument Delimiters in a Command ('Argument
Injection'), credit to abhinavagarwal07
- - Fixed null-deref warning in tokenize_on_space, promote strict-warnings
to required
- - Added a number of tests in CI, including rename, chmod, fsync, statvfs
values, error paths, option coverage
- - Fixed malformed SFTP reply handling
- - Hardened Github Actions workflow with SHA pins, permissions, timeouts,
and dependabot

Thanks for all your efforts and continued support of SSHFS.

[sshfs] SSHFS 3.7.5 released

[H T. <hao...@gm...>]

Hi all,

It's been a number of years and a few new maintainers have stepped up to
contribute to SSHFS. There's been a lot of small changes here and there,
and it's mostly been stable. I don't believe any large new features have
been added, so there should be relatively low risk. Fingers crossed!

I thought therefore it's a good time to make a new release. This is
available on https://github.com/libfuse/sshfs/releases/tag/sshfs-3.7.5

New changes (pasted over from Github):


   - Implement connect to vsock. by @g-easy <https://github.com/g-easy> in
   #277 <https://github.com/libfuse/sshfs/pull/277>
   - 👷 use latest major version for actions/checkout by @thomasmerz
   <https://github.com/thomasmerz> in #289
   <https://github.com/libfuse/sshfs/pull/289>
   - remove README.rst file since README.md file exists by @h4sh5
   <https://github.com/h4sh5> in #295
   <https://github.com/libfuse/sshfs/pull/295>
   - Fix memleak in cache after readlink by @jpalus
   <https://github.com/jpalus> in #305
   <https://github.com/libfuse/sshfs/pull/305>
   - Fill stat info when returning cached data for readdir by @jpalus
   <https://github.com/jpalus> in #306
   <https://github.com/libfuse/sshfs/pull/306>
   - Windows native OpenSSH fix by @manu0401 <https://github.com/manu0401>
   in #314 <https://github.com/libfuse/sshfs/pull/314>
   - Add support for macOS (macFUSE 4.10.0) by @bfleischer
   <https://github.com/bfleischer> in #325
   <https://github.com/libfuse/sshfs/pull/325>
   - ipv6 support for directport connection by @h4sh5
   <https://github.com/h4sh5> in #336
   <https://github.com/libfuse/sshfs/pull/336>

Please test out the new release, and report back any issues to
https://github.com/libfuse/sshfs/issues.

Best regards,
Hash

[sshfs] non-reconnecting sshfs and unkillable processes / unusable with quirky network (firewall)

[Dr. T. O. <tho...@un...>]

Hi,

I'm running an sshfs client on a VM that gets a number of directories
from a server. The client and the server are permanently online in a
datacenter context. They have rather stable connection, but there's
some firewalling between them that I _suspect_ interferes with sshfs.

After some time, in the scale of days, the sshfs connections freeze.
The mounts get stuck, the ssh/sftp processes behind sshfs just hang
there. Any process accessing the mounts gets stuck in uninterruptible
sleep. I once had a workaround in place that rebooted the server each
night. That reduced the pain, but is undesirable for other reasons
(killing cron jobs, for example).

I suppose this is some bad interaction with either the virtual machine
networking or the firewalling between the client and the server, or a
combination of all. At any rate: ServerAliveInterval=15 should cover
this, no?

I do not see reconnects fixing the mounts. I don't see I/O errors, ever
… I just have processes being stuck in unterruptible sleep.

For reasons, I got a somewhat complex setup with a main mount

# fstab
us...@fs...:       /mnt/writable    fuse.sshfs      _netdev,delay_connect,port=26,identityfile=/home/user/.ssh/id_rsa,reconnect,ServerAliveInterval=15,ServerAliveCountMax=2,allow_other 0 0

and sub-directories of this being bind-mounted to other locations
(mounting the sub-directories directly failed right away for some
reason, I noted that back then and just went with the bind mounts).

/mnt/writable/foo/bar /mnt/other/foo/bar  none bind 0 0
/mnt/writable/foo/baz /mnt/other/foo/baz  none bind 0 0

Anything trying to access the mount points gets stuck. There is a
webserver trying to serve from the sshfs mounts that I naturally cannot
stop. An I/O error would be a big improvement!

root@client:~# cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.4 LTS"
root@client:~# sshfs --version
SSHFS version 3.7.1
FUSE library version 3.10.5
using FUSE kernel interface version 7.31
fusermount3 version: 3.10.5

I cannot detail the network setup, except that it _should_ be
physically stable, with redundant links and all. I just take a guess at
firewalling doing weird stuff. At any rate: sshfs should at some point
diagnose a broken connection, but doesn't. The ssh connections just
seem to hang around, doing nothing.

I did `kill -9` on all ssh/sftp processes and eventually they seem to
be re-started, but that does not seem to affect frozen processes at
all. I am not sure, but this does seem to make mounts available to new
processes, but does not affect the frozen ones at all.

For clarity, the man page states:

       If it is acceptable to discard data being read or written, a
       quick workaround is to kill the responsible sshfs process, which
       will make  any  blocking  operations  on  the  mounted
       filesystem  error out and thereby "unfreeze" the relevant
       applications. Note that force unmounting with fusermount -zu, on
       the other hand, does not help in this case and will leave
       read/write operations in the blocking state.

Is this relating to the mount.fuse.sshfs process or to the ssh started
for the actual connection? Also, for multiple mounts it's not that easy
to figure out which ssh/sftp process is the right one (ppid 1 on all of
them?).

What finally worked now is `umount -f` on the mount points (after some
time messing around). I might try a more structured approach with this
next time.

What is clear, after some years of experience with this now, is that
any auto-healing of the sshfs mount, even with I/O errors, is just not
happening.

Also: Isn't it possible to make the processes killable? `kill -9` is
supposed to work on stuck client processes on NFS. Why not with SSHFS?
A FUSE limitation, I presume …

Anyway, I'm thankful for any hints. Mainly, I wanted to have this
documented at least. SSHFS is, sadly, no option for permanent mounts.
It has an appeal because it offers Unix semantics, secure transport, and
passwordless authentication without further infrastructure, but it does
not like our network setup. I guess a properly broken network
connection would be easier, not whatever happens here with the
firewalling.


Alrighty then,

Thomas


PS: I am moving away from this setup, also for hardware reasons, but
wanted to finally give note about this particularily seriously
non-workable sshfs setup. Any hints might be useful should I try some
semi-permanent sshfs again. But so far, the experience gives me caution
to try.

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg

Re: [sshfs] Trying to build sshfs under macOS (11.7 BigSur)

[Christoph K. <ku...@ku...>]

Hi Haoxi,

thanks for your remarks. I'm aware that the syntax of the command was wrong. That was not my problem.
I just wanted to point out to the maintainers, that a program should not segfault, whatever the command line would be.
This could be a security issue.

--
Christoph


> Am 16.10.2023 um 22:15 schrieb Haoxi Tan <hao...@gm...>:
> 
> Hi Christoph,
> 
> I don't think at the mome 3.7.3 will build for Mac, since it depends on a version of FUSE that Mac doesn't support. 
> 
> The only actively maintained sshfs for mac I can find is here 
> https://github.com/tormodwill/macSSHFS <https://github.com/tormodwill/macSSHFS>, maybe try to build that from source? 
> 
> Also, I don't think 2.10 being too old might be the problem here; the segmentation fault might be a different problem, such as the fact that no mountpoint was specified.
> 
> try:
> $ mkdir remote
> $ sshfs foo@bar: remote/
> 
> 
> On Tue, 17 Oct 2023 at 01:35, Christoph Kukulies via fuse-sshfs <fus...@li... <mailto:fus...@li...>> wrote:
> I was suffering from some problems with sshfs mounts under was told, my 2.10 was too old.
> 
> $ sshfs foo@bar: 
> Segmentation fault: 11
> $ 
> 
> So I git cloned sshfs 3.7.3 and tried to build with the following result:
> 
> 
> $ pwd
> /Users/kuku/Downloads/sshfs-3.7.3/build
> $ meson ..
> The Meson build system
> Version: 1.1.1
> Source dir: /Users/kuku/Downloads/sshfs-3.7.3
> Build dir: /Users/kuku/Downloads/sshfs-3.7.3/build
> Build type: native build
> Project name: sshfs
> Project version: 3.7.3
> C compiler for the host machine: cc (clang 13.0.0 "Apple clang version 13.0.0 (clang-1300.0.29.3)")
> C linker for the host machine: cc ld64 711
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> ../meson.build:5: WARNING: Consider using the built-in warning_level option instead of using "-Wall".
> ../meson.build:5: WARNING: Consider using the built-in warning_level option instead of using "-Wextra".
> Program rst2man.py found: YES (/Users/kuku/anaconda3/bin/rst2man.py)
> Configuring config.h using configuration
> Found pkg-config: /opt/local/bin/pkg-config (0.29.2)
> Found CMake: /opt/local/bin/cmake (3.24.4)
> Run-time dependency fuse3 found: NO (tried pkgconfig, framework and cmake)
> 
> ../meson.build:47:15: ERROR: Dependency "fuse3" not found, tried pkgconfig, framework and cmake
> 
> A full log can be found at /Users/kuku/Downloads/sshfs-3.7.3/build/meson-logs/meson-log.txt
> WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
> 
> Here I stand at the moment, not knowing how to preceed.
> 
> --
> Christoph
> 
> 
> 
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li... <mailto:fus...@li...>
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs <https://lists.sourceforge.net/lists/listinfo/fuse-sshfs>

Re: [sshfs] Trying to build sshfs under macOS (11.7 BigSur)

[Haoxi T. <hao...@gm...>]

Hi Christoph,

I don't think at the mome 3.7.3 will build for Mac, since it depends on a
version of FUSE that Mac doesn't support.

The only actively maintained sshfs for mac I can find is here
https://github.com/tormodwill/macSSHFS, maybe try to build that from
source?

Also, I don't think 2.10 being too old might be the problem here; the
segmentation fault might be a different problem, such as the fact that no
mountpoint was specified.

try:
$ mkdir remote
$ sshfs foo@bar: remote/


On Tue, 17 Oct 2023 at 01:35, Christoph Kukulies via fuse-sshfs <
fus...@li...> wrote:

> I was suffering from some problems with sshfs mounts under was told, my
> 2.10 was too old.
>
> $ sshfs foo@bar:
> Segmentation fault: 11
> $
>
> So I git cloned sshfs 3.7.3 and tried to build with the following result:
>
>
> $ pwd
> /Users/kuku/Downloads/sshfs-3.7.3/build
> $ meson ..
> The Meson build system
> Version: 1.1.1
> Source dir: /Users/kuku/Downloads/sshfs-3.7.3
> Build dir: /Users/kuku/Downloads/sshfs-3.7.3/build
> Build type: native build
> Project name: sshfs
> Project version: 3.7.3
> C compiler for the host machine: cc (clang 13.0.0 "Apple clang version
> 13.0.0 (clang-1300.0.29.3)")
> C linker for the host machine: cc ld64 711
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> ../meson.build:5: WARNING: Consider using the built-in warning_level
> option instead of using "-Wall".
> ../meson.build:5: WARNING: Consider using the built-in warning_level
> option instead of using "-Wextra".
> Program rst2man.py found: YES (/Users/kuku/anaconda3/bin/rst2man.py)
> Configuring config.h using configuration
> Found pkg-config: /opt/local/bin/pkg-config (0.29.2)
> Found CMake: /opt/local/bin/cmake (3.24.4)
> Run-time dependency fuse3 found: NO (tried pkgconfig, framework and cmake)
>
> ../meson.build:47:15: ERROR: Dependency "fuse3" not found, tried
> pkgconfig, framework and cmake
>
> A full log can be found
> at /Users/kuku/Downloads/sshfs-3.7.3/build/meson-logs/meson-log.txt
> WARNING: Running the setup command as `meson [options]` instead of `meson
> setup [options]` is ambiguous and deprecated.
>
> Here I stand at the moment, not knowing how to preceed.
>
> --
> Christoph
>
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
>

[sshfs] Trying to build sshfs under macOS (11.7 BigSur)

[Christoph K. <ku...@ku...>]

I was suffering from some problems with sshfs mounts under was told, my 2.10 was too old.

$ sshfs foo@bar: 
Segmentation fault: 11
$ 

So I git cloned sshfs 3.7.3 and tried to build with the following result:


$ pwd
/Users/kuku/Downloads/sshfs-3.7.3/build
$ meson ..
The Meson build system
Version: 1.1.1
Source dir: /Users/kuku/Downloads/sshfs-3.7.3
Build dir: /Users/kuku/Downloads/sshfs-3.7.3/build
Build type: native build
Project name: sshfs
Project version: 3.7.3
C compiler for the host machine: cc (clang 13.0.0 "Apple clang version 13.0.0 (clang-1300.0.29.3)")
C linker for the host machine: cc ld64 711
Host machine cpu family: x86_64
Host machine cpu: x86_64
../meson.build:5: WARNING: Consider using the built-in warning_level option instead of using "-Wall".
../meson.build:5: WARNING: Consider using the built-in warning_level option instead of using "-Wextra".
Program rst2man.py found: YES (/Users/kuku/anaconda3/bin/rst2man.py)
Configuring config.h using configuration
Found pkg-config: /opt/local/bin/pkg-config (0.29.2)
Found CMake: /opt/local/bin/cmake (3.24.4)
Run-time dependency fuse3 found: NO (tried pkgconfig, framework and cmake)

../meson.build:47:15: ERROR: Dependency "fuse3" not found, tried pkgconfig, framework and cmake

A full log can be found at /Users/kuku/Downloads/sshfs-3.7.3/build/meson-logs/meson-log.txt
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.

Here I stand at the moment, not knowing how to preceed.

--
Christoph

Re: [sshfs] SSHFS 3.7.4 released

[Haoxi T. <hao...@gm...>]

The reported bug by Eberhard has been fixed by reverting the PR that
introduced very complex, potentially untested request size negotiation
logic that may cause deadlocks.

The fixed release is here
https://github.com/deadbeefsociety/sshfs/releases/tag/sshfs-3.7.4a

Thanks for the bug report! Please keep them coming.

Warm regards,
Haoxi

On Thu, Sep 21, 2023 at 10:45 PM Eberhard Kuemmerle
<e.k...@fz...> wrote:
>
> Hi,
>
> I have severe problems with sshfs-3.7.4, see my bug report here: https://bugzilla.suse.com/show_bug.cgi?id=1215574
>
> Best regards,
>   Eberhard
>
>
> Am 14.09.23 um 00:25 schrieb Haoxi Tan:
>
> Hi all,
>
> It's been a while.. So I thought, let's package up all the changes and
> fixes made in the past year or so and put it in a release.
>
> https://github.com/deadbeefsociety/sshfs/releases/tag/sshfs-3.7.4
>
> Changelog:
>
> - Support request size negotiation and increased throughput on
> high-latency connections
> - Supports connecting to vsock (7) via shfs -o vsock=CID:PORT
> - README in markdown instead of rst
> - Various test fixes
>
> This is the first release since the last maintainer, and not much has
> changed. Now there's a rudimentary Github Actions CI/CD that builds
> and runs the tests, which will make future PRs much easier.
>
> Please help test it if you'd like, report bugs, and if you're a distro
> maintainer, put it into your bleeding edge and testing branches; after
> a couple months to a year of stability, hopefully this would be ready
> to be merged into stable distro releases.
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs

Re: [sshfs] SSHFS 3.7.4 released

[Haoxi T. <hao...@gm...>]

Hi Eberhard,

First of all thanks for the bug report!

You said in your bug report that
> but when I try to login graphically, the login hangs because many processes hang with status "D":
>The sshfs process does not die but file access to the sshfs filesystem is then no longer possible.

Since SSHFS uses fuse, under potentially unstable network conditions
(or just high load with a directory that has a LOT of files in it and
recursive folders), it can in fact hang and cause file manager and
other processes that use the GUI to hang. I have experienced similar
situations before.

Can you provide some brief info about:
- what's your uname -a
- was sshfs the only software you updated recently?
- how many files do you have in the mounted directory? (output of find . | wc)

If it's possible, I would also like some logs with sshfs running in
debug mode (-d) and a coredump of sshfs while it is hanging as well.
You can probably generate a core file by SSH'ing into the stuck
machine / switching to a TTY and just gcore'ing the sshfs process. If
you don't want to provide any of that it's fine, I can try to
replicate the problem once you give me the exact OS and kernel version
so I can replicate the bug.

Warm regards,
Haoxi

On Thu, Sep 21, 2023 at 10:45 PM Eberhard Kuemmerle
<e.k...@fz...> wrote:
>
> Hi,
>
> I have severe problems with sshfs-3.7.4, see my bug report here: https://bugzilla.suse.com/show_bug.cgi?id=1215574
>
> Best regards,
>   Eberhard
>
>
> Am 14.09.23 um 00:25 schrieb Haoxi Tan:
>
> Hi all,
>
> It's been a while.. So I thought, let's package up all the changes and
> fixes made in the past year or so and put it in a release.
>
> https://github.com/deadbeefsociety/sshfs/releases/tag/sshfs-3.7.4
>
> Changelog:
>
> - Support request size negotiation and increased throughput on
> high-latency connections
> - Supports connecting to vsock (7) via shfs -o vsock=CID:PORT
> - README in markdown instead of rst
> - Various test fixes
>
> This is the first release since the last maintainer, and not much has
> changed. Now there's a rudimentary Github Actions CI/CD that builds
> and runs the tests, which will make future PRs much easier.
>
> Please help test it if you'd like, report bugs, and if you're a distro
> maintainer, put it into your bleeding edge and testing branches; after
> a couple months to a year of stability, hopefully this would be ready
> to be merged into stable distro releases.
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs

Re: [sshfs] SSHFS 3.7.4 released

[Eberhard K. <e.k...@fz...>]

Hi,

I have severe problems with sshfs-3.7.4, see my bug report here: 
https://bugzilla.suse.com/show_bug.cgi?id=1215574

Best regards,
   Eberhard


Am 14.09.23 um 00:25 schrieb Haoxi Tan:
> Hi all,
>
> It's been a while.. So I thought, let's package up all the changes and
> fixes made in the past year or so and put it in a release.
>
> https://github.com/deadbeefsociety/sshfs/releases/tag/sshfs-3.7.4
>
> Changelog:
>
> - Support request size negotiation and increased throughput on
> high-latency connections
> - Supports connecting to vsock (7) via shfs -o vsock=CID:PORT
> - README in markdown instead of rst
> - Various test fixes
>
> This is the first release since the last maintainer, and not much has
> changed. Now there's a rudimentary Github Actions CI/CD that builds
> and runs the tests, which will make future PRs much easier.
>
> Please help test it if you'd like, report bugs, and if you're a distro
> maintainer, put it into your bleeding edge and testing branches; after
> a couple months to a year of stability, hopefully this would be ready
> to be merged into stable distro releases.
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs

Re: [sshfs] SSHFS 3.7.4 released

[<c....@po...>]

Dear Haoxi Tan,

thanks for this information and your work in that project.

I'm member of maintenance team of "Back In Time" using sshfs. We will 
report back if somethings comes up.

Kind
Christian Buhtz
https://github.com/bit-team/backintime

[sshfs] SSHFS 3.7.4 released

[Haoxi T. <hao...@gm...>]

Hi all,

It's been a while.. So I thought, let's package up all the changes and
fixes made in the past year or so and put it in a release.

https://github.com/deadbeefsociety/sshfs/releases/tag/sshfs-3.7.4

Changelog:

- Support request size negotiation and increased throughput on
high-latency connections
- Supports connecting to vsock (7) via shfs -o vsock=CID:PORT
- README in markdown instead of rst
- Various test fixes

This is the first release since the last maintainer, and not much has
changed. Now there's a rudimentary Github Actions CI/CD that builds
and runs the tests, which will make future PRs much easier.

Please help test it if you'd like, report bugs, and if you're a distro
maintainer, put it into your bleeding edge and testing branches; after
a couple months to a year of stability, hopefully this would be ready
to be merged into stable distro releases.

Re: [sshfs] SSHFS freezes in bash but not in tsch‏‏

[ערן <exx...@gm...>]

There was a typo in the original email. I meant tcsh, and not "tsch":
https://en.wikipedia.org/wiki/Tcsh

Thanks for your help!

‫בתאריך יום ד׳, 12 ביולי 2023 ב-13:15 מאת ערן <‪exx...@gm...‬‏>:‬

> Hi,
>
> I run SSHFS on a cluster which I am not root on.
> Therefore, I use SSHFS 2.4 (as it does not require installing fuse which I
> cannot as I'm not root, also I am able to run the executable out of the box
> without apt install).
> I am able to mount the following partition in tsch:
>
>     echo "CENSORED" | ./sshfs/bin/sshfs -o password_stdin -o
> StrictHostKeyChecking=no CEN...@CE...:/
> /SOME/CENSORED/PATH
>
> But in bash something strange happens.
> There is a blank line in the terminal. It waits a minute and then:
>
>     Timeout waiting for prompt
>
> It seems to be unrelated to wait for fingerprint approval, as
> StrictHostKeyChecking is applied.
> This is strange as it happens in bash but not tsch. Maybe it is a
> bash related issue?
>
>     Distributor ID: Ubuntu
>     Description: Ubuntu 18.04.3 LTS
>     Release: 18.04
>     Codename: bionic
>
> Thanks!
>
>

[sshfs] SSHFS freezes in bash but not in tsch‏‏

[ערן <exx...@gm...>]

Hi,

I run SSHFS on a cluster which I am not root on.
Therefore, I use SSHFS 2.4 (as it does not require installing fuse which I
cannot as I'm not root, also I am able to run the executable out of the box
without apt install).
I am able to mount the following partition in tsch:

    echo "CENSORED" | ./sshfs/bin/sshfs -o password_stdin -o
StrictHostKeyChecking=no CEN...@CE...:/ /SOME/CENSORED/PATH

But in bash something strange happens.
There is a blank line in the terminal. It waits a minute and then:

    Timeout waiting for prompt

It seems to be unrelated to wait for fingerprint approval, as
StrictHostKeyChecking is applied.
This is strange as it happens in bash but not tsch. Maybe it is a
bash related issue?

    Distributor ID: Ubuntu
    Description: Ubuntu 18.04.3 LTS
    Release: 18.04
    Codename: bionic

Thanks!

[sshfs] Why is it important to have the same "locale" on Client and Server?

[<c....@po...>]

Hello,

when using sshfs (also ssh, sftp and other SSH based tools) some people 
do get an "Setting locales failed" error from the server and the 
connection is closed.

I do understand why this happens and I also know how to "solve" or 
workaround it. The internet is full with "solutions".

But what I would like to understand is why it is important to have the 
same locale on Server and Client?

And if it is important (e.g. because of understanding file names) such 
an error should be treated serious and not worked around with all the 
"solutions" from the internet.

Thanks in advance
Christian Buhtz

Re: [sshfs] Member of permission user group "fuse"

[Greg T. <gd...@le...>]

c....@po... writes:

> So can you tell me something about the history of this
> fuse-group-thing and how it is related to the present days?

In addition to the other answer, the whole concept of "fuse" group is a
local matter on some particular operating system, surely intended to
gatekeep the use of mounting a fuse filesystem into the system
namespace.  It's not really about sshfs.  My very hazy impression is
that the trend is towards allowing user mounts, but with nodev,nosuid
mount options (that's BSD speak).

But if even one system will mount sshfs without  being in fuse, the
check is wrong, and you should just get rid of it, and focus on handling
errors from sshfs instead -- and of course you need to do that anyway.

Re: [sshfs] Member of permission user group "fuse"

[Haoxi T. <hao...@gm...>]

Hi Christian,

I have checked on Fedora, Debian and Ubuntu, and based on my knowledge
I can confirm that the fuse user groups are not needed in any of those
distros.

FUSE has been a kernel feature for a while. If you want to check that
fuse is enabled in a system, you could check for the existance of
/dev/fuse https://www.kernel.org/doc/html/latest/filesystems/fuse.html

I would recommend removing that useless check and see if anything
breaks. My best guess is nothing will.

Best regards,
Haoxi

On Thu, Jun 29, 2023 at 11:41 PM <c....@po...> wrote:
>
> Hello together,
>
> based on (https://github.com/libfuse/sshfs) I'm aware that sshfs is
> orphaned. But I hope that someone with knowledge about the internals and
> the history of "sshfs" can validate an information/hypothesis for me.
>
> In short: Today does a user need to be member of the user group "fuse"
> to use "sshfs" ? I do not understand the technical details or
> implications of it, that is my problem.
>
> Background of this question: Looking around in the internet's forums,
> (maybe outdated?) wikis and other support channels like stackoverflow I
> often found the hint that a user should be part of the group "fuse". In
> some cases this solved the problems. But most of this support threads
> are years old. In more up-2-date locations like the Arch or Ubuntu Wiki
> I can not find this information anymore. It seems to me that a user
> don't need to be part of the "fuse" group anymore.
>
> More background: I'm an upstream maintainer of a backup software [1]
> also using sshfs in the back. With some other folks I took over the
> project last year. Because of some fuse-group-problems in the year 2013
> a fix was introduced. The application do check if the user is member of
> "fuse" group if it exists and also do some error checking and messaging
> around this topic.
> My hypothesis is that this fuse-group-thing isn't needed anymore today
> so the relevant code can be removed from the project [2].
>
> So can you tell me something about the history of this fuse-group-thing
> and how it is related to the present days?
>
> Thanks in advance
> Christian Buhtz
> Member of maintenance team "Back In Time"
>
> [1] -- <https://github.com/bit-team/backintime>
> [2] --
> <https://github.com/bit-team/backintime/issues/1450#issuecomment-1597035415>
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs

[sshfs] Member of permission user group "fuse"

[<c....@po...>]

Hello together,

based on (https://github.com/libfuse/sshfs) I'm aware that sshfs is 
orphaned. But I hope that someone with knowledge about the internals and 
the history of "sshfs" can validate an information/hypothesis for me.

In short: Today does a user need to be member of the user group "fuse" 
to use "sshfs" ? I do not understand the technical details or 
implications of it, that is my problem.

Background of this question: Looking around in the internet's forums, 
(maybe outdated?) wikis and other support channels like stackoverflow I 
often found the hint that a user should be part of the group "fuse". In 
some cases this solved the problems. But most of this support threads 
are years old. In more up-2-date locations like the Arch or Ubuntu Wiki 
I can not find this information anymore. It seems to me that a user 
don't need to be part of the "fuse" group anymore.

More background: I'm an upstream maintainer of a backup software [1] 
also using sshfs in the back. With some other folks I took over the 
project last year. Because of some fuse-group-problems in the year 2013 
a fix was introduced. The application do check if the user is member of 
"fuse" group if it exists and also do some error checking and messaging 
around this topic.
My hypothesis is that this fuse-group-thing isn't needed anymore today 
so the relevant code can be removed from the project [2].

So can you tell me something about the history of this fuse-group-thing 
and how it is related to the present days?

Thanks in advance
Christian Buhtz
Member of maintenance team "Back In Time"

[1] -- <https://github.com/bit-team/backintime>
[2] -- 
<https://github.com/bit-team/backintime/issues/1450#issuecomment-1597035415>

Re: [sshfs] sshfs with option idmap=file does not work at all

[Nikolaus R. <Nik...@ra...>]

On Feb 21 2023, Johann Petrak <joh...@gm...> wrote:
> I completely understand that volunteers and former contributors may not
> have the time to look into this, but
> I am a bit frustrated that such an important part of linux apparently does
> not receive the attention and (financial, time)
> support by (commercial) downstream Linux distributors.

Welcome to the world of open source.

> Just so I understand things correctly: is the archived sshfs repo the most
> recent source code repository for the sshfs
> everyone and their dog are using all over the glob? ( insert wide-eye-emoji
> here).

I don't think this is a question that anyone can answer
authoritatively. My personal guess is that this is true.

If you look at the archives for this list, I think there have been at
least two annoucements of forking and/or resuming maintenance of SSHFS
(one of them by porting to Rust). I am not sure if any of them ever got
traction.


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: [sshfs] sshfs with option idmap=file does not work at all

[Haoxi T. <hao...@gm...>]

Hi Johann,

>From useful forks (https://useful-forks.github.io/?repo=libfuse/sshfs)
it looks like the most up to date (unofficial) repo is
https://github.com/deadbeefsociety/sshfs - this one I am in charge of
maintaining. It contains merged PRs that were not merged in the
archived sshfs repo, as well as code from a couple of other forks. The
second most recent is https://github.com/neunenak/sshfs which is as of
last year being ported to Rust. It doesn't look like there were any
activities on either since last year since life happens and what not.
Most maintainers are still using the archived version.

I didn't get a lot of pull requests on the deadbeefsociety fork,
there's been one issue so far, if you can raise the issue you
mentioned above to there that'd be great. Feel free to just copy some
stuff from your emails above to put it in.

Thanks,
Haoxi

On Tue, Feb 21, 2023 at 7:37 PM Johann Petrak <joh...@gm...> wrote:
>
>
>
> On Tue, 21 Feb 2023 at 10:15, Nikolaus Rath <nik...@ra...> wrote:
>>
>> On Tue, 21 Feb 2023, at 09:09, Nikolaus Rath wrote:
>>
>> On Tue, 21 Feb 2023, at 07:21, Johann Petrak wrote:
>>
>> BTW, could I ask if using that option works for anyone else? I have tried this on quite a number of different computers,
>> with the same result everywhere: does not work.
>>
>>
>> It looks like you also filed a bug, https://github.com/libfuse/libfuse/issues/738. Let's continue the discussion there, so that things are in one place.
>>
>>
>> Nevermind my previous email, I just noticed that this was reported against libfuse rather than SSHFS. So this list is the best place for discussing it.
>>
>
> Yes, sorry, I was reluctant to report in the sshfs repo since it is archived and I believe I read somewhere to report problems to libfuse.
>
>
>>
>> For what it's worth, I am seeing the same behavior:
>>
>> nikratio@vostro ~/tmp> sshfs -f ebox: mnt -o idmap=file,uidfile=uidfile.txt,gidfile=gidfile.txt
>> nikratio@vostro ~/tmp [1]>
>>
>
> Thanks for confirming this behavior!
>
> I completely understand that volunteers and former contributors may not have the time to look into this, but
> I am a bit frustrated that such an important part of linux apparently does not receive the attention and (financial, time)
> support by (commercial) downstream Linux distributors.
>
> Unfortunately I am not a C programmer and know almost nothing about the underlying libraries and methods, so
> not sure if I could be of any help here.
>
> Just so I understand things correctly: is the archived sshfs repo the most recent source code repository for the sshfs
> everyone and their dog are using all over the glob? ( insert wide-eye-emoji here).
>
> Cheers,
>    Johann
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs

Re: [sshfs] sshfs with option idmap=file does not work at all

[Johann P. <joh...@gm...>]

On Tue, 21 Feb 2023 at 10:15, Nikolaus Rath <nik...@ra...> wrote:

> On Tue, 21 Feb 2023, at 09:09, Nikolaus Rath wrote:
>
> On Tue, 21 Feb 2023, at 07:21, Johann Petrak wrote:
>
> BTW, could I ask if using that option works for anyone else? I have tried
> this on quite a number of different computers,
> with the same result everywhere: does not work.
>
>
> It looks like you also filed a bug,
> https://github.com/libfuse/libfuse/issues/738. Let's continue the
> discussion there, so that things are in one place.
>
>
> Nevermind my previous email, I just noticed that this was reported against
> libfuse rather than SSHFS. So this list is the best place for discussing
> it.
>
>
Yes, sorry, I was reluctant to report in the sshfs repo since it is
archived and I believe I read somewhere to report problems to libfuse.



> For what it's worth, I am seeing the same behavior:
>
> nikratio@vostro ~/tmp> sshfs -f ebox: mnt -o
> idmap=file,uidfile=uidfile.txt,gidfile=gidfile.txt
> nikratio@vostro ~/tmp [1]>
>
>
Thanks for confirming this behavior!

I completely understand that volunteers and former contributors may not
have the time to look into this, but
I am a bit frustrated that such an important part of linux apparently does
not receive the attention and (financial, time)
support by (commercial) downstream Linux distributors.

Unfortunately I am not a C programmer and know almost nothing about the
underlying libraries and methods, so
not sure if I could be of any help here.

Just so I understand things correctly: is the archived sshfs repo the most
recent source code repository for the sshfs
everyone and their dog are using all over the glob? ( insert wide-eye-emoji
here).

Cheers,
   Johann