Bug 73809 - systemd --user mount targets with -t option fails due to lack of root privileges
Summary: systemd --user mount targets with -t option fails due to lack of root privileges
Status: NEW
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-19 20:07 UTC by kovariadam
Modified: 2019-10-05 17:49 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kovariadam 2014-01-19 20:07:47 UTC
I am not quite sure whether this is a problem of systemd itself but it would be nice if mount target worked properly even in user mode. It fails now(F20) as mount target uses -t option which needs root.

mount -t unified unified/
mount: only root can use "--types" option

unified is my virtual fuse filesystem. Could this feature be somehow available even for user systemd process?

Thanks
Comment 1 Zbigniew Jedrzejewski-Szmek 2015-01-12 05:19:46 UTC
I don't think there's much we can do here. systemd user instances don't run as root. I guess it would be up to /bin/mount to relax its rules and allow -t for unprivileged callers in some cases.
Comment 2 Karel Zak 2015-01-12 13:42:04 UTC
I'm really not sure if I want to play with this and open Pandora's box. It's fine to call 

 mount /path

and have all necessary properties in /etc/fstab.

If systemd user instances don't run as root then why does it call root-only commands (like mount -t)? IMHO you can improve systemd to use "mount /path" and assume usable fstab setting if executed as non-root.
Comment 3 kovariadam 2015-01-12 13:52:59 UTC
Karel, I think my point is that systemd allows you to create userspace mount targets,

However, they don't really work, since systemd is calling mount -t which is root only. Maybe there could be an option to use fusermount which IIRC works under non-root accounts?

I should probably let you know that we abandoned this project, so I don't really need this anymore.

If you decide that this is the best it gets, feel free to close this BZ.
Comment 4 Zbigniew Jedrzejewski-Szmek 2015-01-12 17:44:34 UTC
OK, maybe we should think about calling fusermount directly.
Comment 5 Dmitrii S. 2016-05-01 16:02:54 UTC
Hi,

Any update on this issue? I've got a similar use case that requires mount options to be passed but, at the same time, I don't need systemd to use 'mount', rather, I need it to use sshfs (or fusermount) so the operation can be performed with user permissions:

systemctl --user start home-administrator-Calibre\\x2dssh.mount

май 01 18:19:00 UX32LN systemd[3196]: Reloading.
май 01 18:19:16 UX32LN systemd[3196]: home-administrator-Calibre\x2dssh.mount: Directory /home/administrator/Calibre-ssh to mount over is not empty, mounting anyway.
май 01 18:19:16 UX32LN systemd[3196]: Mounting Mount calibre library directory via sshfs...
май 01 18:19:16 UX32LN mount[11031]: mount: only root can use "--options" option
май 01 18:19:16 UX32LN systemd[3196]: home-administrator-Calibre\x2dssh.mount: Mount process exited, code=exited status=1
май 01 18:19:16 UX32LN systemd[3196]: Failed to mount Mount calibre library directory via sshfs.
май 01 18:19:16 UX32LN systemd[3196]: home-administrator-Calibre\x2dssh.mount: Unit entered failed state.

home-administrator-Calibre\x2dssh.mount:

[Unit]
Description=Mount calibre library directory via sshfs

[Mount]
What=<my_server>:<my_path>
Where=/home/administrator/Calibre-ssh
Type=fuse.sshfs
Options=reconnect,nonempty,_netdev,noauto,nofail,delay_connect,IdentityFile=<id_path>,user
TimeoutSec=10

[Install]
WantedBy=default.target

Thanks,
D.
Comment 6 Lucas Werkmeister 2016-07-18 12:42:54 UTC
I think systemd could mount at least FUSE filesystems as user by running the FUSE program directly. This would mean translating

[Mount]
What=$what
Where=$where
Type=fuse.$fusetype
Options=$options

to

$fusetype $what $where -o $options

As a bonus, since some FUSE file systems don’t need a source, it would be convenient if What were made optional, translating

[Mount]
Where=$where
Type=fuse.$fusetype
Options=$options

to

$fusetype $where -o $options

(Alternatively, you could run mount.fuse $fusetype#$what $where -o $options, but that doesn’t seem to do much more than adding two default options (dev,suid) and then running the FUSE program normally.)
Comment 7 rektide 2017-12-10 22:47:56 UTC
Please call fusermount instead. It's totally fine if there's a manual flag in [Mount]/fstab-options to make this happen. This is needed to make systemd viable for useful user environments.
Comment 8 rektide 2017-12-10 22:49:06 UTC
(In reply to rektide from comment #7)
> Please call fusermount instead. It's totally fine if there's a manual flag
> in [Mount]/fstab-options to make this happen. This is needed to make systemd
> viable for useful user environments.

Pardon, mount.fuse.
Comment 9 rektide 2017-12-10 22:55:28 UTC
Welp that doesn't appear to work either. Something has to be done to make this ticket viable, to make userland systemd not heinously pathetically crippled & weak.

Perhaps anything detected as /usr/bin/fuse{,23}.[type] could be interpreted as needing to be directly called rather than mount? This is how fuse 2 & fuse 3 apps are differentiating themselves, according to sshfs[1].

[1] https://github.com/libfuse/sshfs/issues/92#issuecomment-328450030
Comment 10 rektide 2017-12-10 22:57:55 UTC
(In reply to rektide from comment #9)
> Perhaps anything detected as /usr/bin/fuse{,23}.[type] could be interpreted
> as needing to be directly called rather than mount? This is how fuse 2 &
> fuse 3 apps are differentiating themselves, according to sshfs[1].
> 
> [1] https://github.com/libfuse/sshfs/issues/92#issuecomment-328450030

Looking further at the work sshfs committed, there's a commit where they create /usr/bin/mount.fuse.sshfs. Detecting if type matches this last componenet ought to be sufficient for detecting the need to divert from use of mount & to a fuse alternative.
Comment 11 Chris 2019-10-05 17:49:28 UTC
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@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?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.