I have two remote servers, foo and bar. On both servers I have a user git (with different uid and gid). Both servers are running Debian distributions. Both servers have their each others' root ssh public key in authorized_keys, so all ssh-related commands already work like a charm.
git accounts have been properly configured - the default shell is set to /usr/bin/git-shell, the repositories are working on foo (bar is still unconfigured in the matter).
I'm trying to create a "shared directory" between foo and bar using sshfs. On foo I have a directory /home/git. The directory belongs to user git (uid/gid 1000 in this case). Let's say I want to mount this folder using sshfs on bar at /mnt/foo-git.
In normal case, I would just use sshfs git@foo /mnt/foo-git (on bar) to mount the directory (or use fstab, which by the way is what I plan to do once I get the system working). However, git-shell effectively prevents me from invoking sftp-server and using the sshfs in the simplest way.
After fiddling around a little, I decided to use the root user to log in (through ssh), change the effective user with su -l, and start sftp-server. To achieve this, I created a simple script (on foo) /sbin/git-sftp-server:
#!/bin/bash
/bin/su -l git -s /bin/bash -c /usr/lib/openssh/sftp-server
And used the following option with sshfs (bar):
sshfs root@foo /mnt/foo-git -o sftp_server=/sbin/git-sftp-server
The command seems to work, however it does not really change the permissions of the session. When I create a file on bar, on foo the file appears with owner root. This becomes a serious problem, when git commands can't change the contents of the repositories, simply because of the basic Linux file access control.
Right now, I see two possible directions:
- Try to force sshfs session with user git. This may require me to fiddle around the git-shell, but might not be impossible
- Find a way to fix su-ing into user git from a root session
Either way, so far I couldn't find a good way to solve the problem, but I count on your advice.
Edit: OK, After reading @AlexStragies comment (and testing few other things) it turns out, that my solution is somewhat working. If I mount the filesystem through sshfs or fstab with +/- the following options:
root@foo:/home/git /mnt/foo-git fuse.sshfs defaults,_netdev,uid=998,gid=998,IdentityFile=/root/.ssh/id_rsa,allow_other,sftp_server=/sbin/git-sftp-server" 0 0
And then su -l into git user with a "normal" shell and create a file, the uid/gid of the file is set properly to git@foo. However, let's say I create a file /home/git/cat with user root@foo and privileges 644. User git@foo obviously cannot modify the file (permission denied, however I was surprised he can remove the file, but I guess that's possible because he has write permission to the folder). On bar machine, the file appears to be owned by the user git, with permissions 644, although it's real owner is root@foo. Now, both users git and root at foo can modify the file cat (with the changes reflected on machine foo) although the file is still owned by root with permissions 644.
This seems like either a weird case of privilege escalation, or a not-really-working workaround. So, my question now is: which one? And if the latter, then what can I do to properly respect the remote user's permissions?
