Better support for Unix sockets

[julien-picalausa]

Greetings,

I am facing a situation where a piece of software I am running is attempting to create a unix socket for local use in the same directory as its configuration files. As it happens, I wish to store those configuration files on a remote server and access them via sshfs, but this isn't possible because the software in question then refuses to start as it cannot create the socket it needs.

I see that at the time being, if a socket is created on the server side, a (presumably) dummy socket is exposed on the client.

I assume it should be possible to have a similar solution which allows a socket to be created on a client, causing a corresponding dummy socket to be created on the server and then subsequently exposed to any other client. However, I can see this could become confusing if multiple clients start deleting and recreating the same socket, causing previously valid sockets on other clients to be replaced with dummies. I imagine that solving that in a consistent and intuitive way is going to be difficult, but it would definitely be nice to have if possible.

Thank you for reading my report and thank you for maintaining fuse-sshfs.

[Nikratio]

This is a great idea, thanks for taking the time to suggest it! Do you think you could work on this (or do you know someone who could)?

SSHFS is a fully volunteer driven project. This means that new features and bugfixes are implemented only when someone has a personal interest in them and therefore also does the necessary work. Suggestions for new features that are just submitted to the issue tracker are therefore unlikely to result in the feature being implemented - as great as the feature might be.

So if someone (that probably means you) is interested in working on this, then I'd be happy to give guidance and review patches. If not, I will close this issue in a few days (since the purpose of the issue tracker is to coordinate ongoing and planned work, rather than enumerate all the work that could possibly be done).

[julien-picalausa]

I've poked a bit around the code and did some experiments to get an idea of how much work it would be to make this work.

It looks like the sftp implementation in OpenSSH doesn't support creating non-regular files server-side, so my original idea is not immediately practical. I can see if the OpenSSH folks are interested in supporting this, but I wonder if it's maybe just better to instead keep track of created sockets locally without involving sftp at all. If a file pops-up on the server side that matches a locally created socket name, it can either be ignored until the socket is removed or it can force the socket to be removed right there and then. Either way, this bypasses any issue with clients potentially deleting each-other's sockets. Let me know if you think that sounds sensible.

I don't know much about the way unix sockets work behind the scene though, so no idea whether getting it to work that way is easy or not.

So, in general, I'm willing to work on this and see if I can sort it out. My time availability tends to be limited though, so it might take a while.

[gralpli]

I’m not sure if this can/should be solved within sshfs at all. Have you tried laying an union filesystem above your configuration files on each client? This way the unix domain socket file wouldn’t be visible to the server at all. Would that suffice your needs?

[julien-picalausa]

@gralpli : I had a quick look into it. Unfortunately, I am on FreeBSD, where the implementation of unionfs is known to be broken, so trying that is not an option for me at least. Even if it was an option, my understanding of unionfs is that it basically directs all file writes to the upper layer and effectively makes the lower layer read only. Since I still want to effectively be able to write regular files and directories to the server, that would probably not work.

[kalvdans]

I agree that only sharing a subset of files in a folder is outside the scope of sshfs, and think this issue should be closed.

It's better solved on the other app, by allowing its config file to point out the location of its UNIX socket.