Hello !
Getting a bit annoyed with permission issues with samba and sshfs. If someone could give me some input on how to find an other more elegant and secure way to share a folder path owned by root, I would really appreciate it !
Context
- The following folder path is owned by root (docker volume):
/var/lib/docker/volumes/syncthing_data/_data/folder
- The child folders are owned by the user server
/var/lib/docker/volumes/syncthing_data/_data/folder
- The user server is in the
sudoersfile - Server is in the docker groupe
fuse.confhas theuser_allow_otheruncommented
Mount point with sshfs
sudo sshfs server@10.0.0.100:/var/lib/docker/volumes/syncthing_data/_data/folder /home/user/folder -o allow_other
Permission denied
Things I tried
- Adding other options like
gid 0,27,1000uid 0,27,1000default_permissions... - Finding my way through stackoverflow, unix.stackexchange...
Solution I found
- Making a bind mount from the root owned path to a new path owned by server
sudo mount --bind /var/lib/docker/volumes/syncthing_data/_data/folder /home/server/folder
- Mount point with sshfs
sshfs server@10.0.0.100:/home/server/folder /home/user/folder
Question
While the above solution works, It overcomplicates my setup and adds an unecessary mount point to my laptop and fstab.
Isn't there a more elegant solution to work directly with the user server (which has root access) to mount the folder with sshfs directly even if the folder path is owned by root?
I mean the user has root access so something like:
sshfs server@10.0.0.100:/home/server/folder /home/user/folder -o allow_other should work even if the first part of the path is owned by root.
Changing owner/permission of the path recursively is out of question !
Thank you for your insights !
Heyha !
Thanks for your input, you pointed the right direction ! After some more reading, this is what I found.
Adding the following line in sudoers file after
@includedir /etc/sudoers.d:server ALL = NOPASSWD: /usr/lib/openssh/sftp-serverWorks without the need of a sudo session for the sftp-server. I have no idea if this is good security practice but If i had to guess I would say no. Having the
NOPASSWDargument for something critical as an ftp server seems... Not a good idea ! But I'm not an expert, so I'm just guessing :/.If I may, how would you tackle such an use case ? My first solution seems way more secure with the right permissions on the bind mount, what do you think ?
Thanks for your nice tip to right direction :D !
As far as I understand, the user server is not the user running your web server e.g. www-data, right? Otherwise I would advise against giving him elevated privileges such as sudo rights.
If the authentication of the user server has sufficiently high level, e.g. a strong password, SSH key authentication, I don't see a high risk in using the NOPASSWD method. But, as I am no expert, please take this with a grain of salt.
Sorry for the late response !
Are you sure about that? I mean, in the sudoers file I added the user server with NOPASSWD and not www-data for the specific service. And it works that way.
Maybe I misunderstand something here, if so please correct me. Is there anyway I could check this out? Do I need to check the owner on my host or my client trying to mount the path?
Thank you !!
By the 'user running the web server' I mean the user running the Apache, Ngix or whatever web server on your system. Usually, afaIk, you should not be able to login as e.g. www-data on the system. You can identify the username by running ps -ef and searching for the web server process. You'll find the corresponding user name in the first column.