[systemd-bugs] [Bug 73809] systemd --user mount targets with -t option fails due to lack of root privileges

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=73809

--- Comment #11 from Chris <systemd-bugs at chris.oldnest.ca> ---
Is there any interest in getting this fixed?

I'm in the same situation as others here, in that I have use-cases in which
user units automounting sshfs via FUSE would be extremely helpful. For example:
family members with separate accounts on a Linux fileserver can all have their
own collections of music, movies, etc. 
* Log in to the server as Alice and you have read/write access to Alice's
library and read-only access to Bob's and Carol's. Cool.
* Alice's single-user client machine can use a systemd 'system' mount/automount
pair to log in (using a root-owned ssh key on the client) as Alice, and get the
same result. So far, so good.
* On a shared laptop, Alice can manually mount the shared media library using
her own ssh key and get the expected access. So can Bob and Carol. Yay FUSE!  
A systemd 'system' unit breaks here, because it can only offer one ssh key
unless you employ some truly hideous hacks to either rewrite the unit file or
rename an ssh key to 'current' or similar whenever a user logs into an X
session, or something. (I don't know whether templating could theoretically
help with this, but it doesn't matter because you can't template a .mount unit
anyway.)
* If systemd were smart enough to see the "Type=fuse.sshfs" and actually use
FUSE to mount it (at *least* when it's a user instance), we would easily be
able to deploy 'user' mount and automount units that use the %h and %u
specifiers to use Alice's ssh key to connect to alice at server and mount the
library (with correct permissions) to a mountpoint in /home/alice/ when running
in Alice's user systemd instance.

But no, currently the options are either a crude "1 client machine == 1 'user'
on the server" mapping via systemd-managed mounts, or if you want proper access
control you bypass systemd and put the sshfs command in a desktop autostart
entry or something.

As a workaround, I suppose I might try building a user .service unit to Exec
the sshfs command and make it PostExec the unmount command at user logout and
explicitly define the dependencies that a .mount unit has implicitly... That
might possibly work, but it sure would be nice if user-level .mount units would
properly handle user-level mount actions instead of rigidly using a root-only
mount command that's guaranteed to fail. And given that FUSE exists
specifically to solve the problem of letting users mount filesystems, having
user .mount units recognize FUSE "Type=" entries and mount them using FUSE just
seems like the right thing to do... doesn't it?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-bugs/attachments/20191005/75e8de35/attachment.html>