Does mounting a backup location via SSHFS change the remote directory permissions?

[james]

Hello @jadudm
Since you are on Cloudron Version 8.3.2 and Cloudron 9 is right around the corner, we just postpone this issue after you've upgraded to Cloudron 9 and see if the issue persists.
Is this acceptable to you?

[nebulon]

After looking into this, that logic hasn't changed there between Cloudron 8 and 9. Last major change there was https://git.cloudron.io/platform/box/-/commit/6ace8d1ac50df2169b28c6a1534cb482526055cd which goes a bit into the details of the chmod. But tbh have to do some more reading up on that bit.

For a start I guess, the issue in your case would go away, if you do not mount the user's HOME but some subfolder of that. Then the 777 should not interfere with the system itself as that subfolder won't be as special as HOME.

[jadudm]

Good thought. I had added a prefix, which didn't make a difference (because I was mounting $HOME), but that might make all the difference. I'll report back after the experiment.

[jadudm]

This solved the problem.

(Editing later: "this" meaning "mounting a path like $HOME/subdir solved the problem, because the permissions on $HOME remained 755, but the permissions on subdir were still changed to 777. This is good, because $HOME has to be 755, or SSH will fail. But...)

I'm still concerned that the remote directory becomes

drwxrwxrwx 3 cbackup cbackup    3 Nov  3 14:33 aloe

which seems awfully permissive. In this instance, I don't have a security threat (or, if someone gets onto the NAS, this is the least of my problems). But once I'm SSH'd into a machine via SSHFS, I'd think that drwx------ would be fine. (Put another way: once Cloudron has the private key, it should not need to set permissions on the remote directory at all... unless this is somehow related to symlinking, or what rsync wants to do, or...)

Either way, many thanks for the good ideas. I think I'm moving forward. We'll call this one closed.

[jadudm]

Another lesson learned. @nebulon , the SSHFS mounting code is kinda fragile, I think. This is still on 8.3.2.

In setting up a volume mount, I tried pasting in an SSH private key.

If I paste in

-----BEGIN ... ----- asdfkljasdflkjasdf alsdkfjals kdfjalskdjf asdlfjkasdlfkjasldfkj -----END ...------

then things do not work. However, if I carefully reformat my key:

-----BEGIN ... -----
asdfkljasdflkjasdf
alsdkfjals
kdfjalskdjf
asdlfjkasdlfkjasldfkj
-----END ...------

and paste it in, then the key works. This matters because I stored my key in a custom field in Bitwarden, and hit the "copy" button in the Bitwarden browser gui. The key came out somewhat mangled.

I would argue the whitespace was safe to split on, and could have been reformatted easily into a good key. However, I had to paste it into Cloudron exactly right, or else I got auth failures.

Maybe that is on me, but it feels like when setting up SSH mounts, splitting and formatting on whitespace is splitting and formatting on whitespace. Given that the whitespace issues are invisible to me (and Cloudron does not help me debug it... nor do the auth.log messages on the remote server), it might be nice if the GUI was a but more forgiving, or able to give me a hint.

Food for thought, anyway. I don't know if/how much of my issues have been this vs. other challenges. (I know the permissions issue is real, and repeatable. This also seems to be repeatable.)

Good luck; the v9 firehose seems real...

[jadudm]

And, while I'm at it...

This came up because I had set up:

1. Backups
2. An SSHFS mount for NextCloud
3. A separate SSHFS mount for Navidrome

All of these connections worked. I even went through multiple backup cycles.

Then, this afternoon, the mounts all failed.

I cannot determine what caused it. I was able to reset some keys, and get mounts to work. But, now, my mounts are failing again, and I suspect I'm going to find permissions/other issues. I cannot yet get to a root cause.

1. I am very suspicious of Cloudron's SSHFS mount code. Given that it seems to make aggressive permission changes, I'm worried. That said,
2. It could be something about TrueNAS Scale. That said, it is "just" a Debian. On the other hand, I've never worked with ZFS or TrueNAS. So... is there something going on, where permissions are shifting?

What bothers me is that I can, from both my Cloudron host and my local machine, use the SSH keys in question without difficulty. So, I am not inclined to believe that TrueNAS is doing something odd, given that the standard SSH from a Linux command line can connect, but Cloudron fails to make mounts. Something is breaking, and I don't know if I have the right logs/tools to debug what is going on in Box.

Happy to do what I can to help.

[jadudm]

And...

Reading

https://superuser.com/questions/1477472/openssh-public-key-file-format

and digging in to some of the RFCs a bit deeper, it seems like this is a complex, largely unspecified space.

It might be good if Cloudron:

1. Was clear about what format it could ingest, and
2. Considered accepting a file upload for the private key

as opposed to dealing with copy-paste. But, either way... being clear about what was expected from us for the key (at least as far as Cloudron is concerned) would be good.

[nebulon]

@jadudm maybe you can make a feature request here to format the key (removing whitespace, adding newlines) when pasted into the textarea. This should be possible for the dashboard code.

[jadudm]

@nebulon , will do. I realized I can probably also dig around on my instance and look at what the mounting scripts are doing to debug further. Many thanks.

[jadudm]

@nebulon , per request:

https://forum.cloudron.io/topic/14525/improving-user-experience-with-ssh-keys-for-sshfs-and-volume-mounts

Many, many thanks. And, if I find anything useful, I'll update that thread. Or, this one, and cross-link.