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-06-03 17:57 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.


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.