umount: only root can use "--types" option

[jsoref]

System information

Type	Version/Name
Distribution Name	Ubuntu
Distribution Version	bionic (18.04.2)
Linux Kernel	4.15.0-46-generic
Architecture	x86_64
ZFS Version	0.7.5-1ubuntu16
SPL Version	0.7.5-1ubuntu1

Describe the problem you're observing

When I try to create a volume as a non root user, I get a pretty warning explaining that as a non root user zfs can't mount the volume.
When I try to destroy a volume as a non root user, I get a technical warning (from /bin/umount)

The equivalent error can be seen here:

$ /bin/umount x --types foo
umount: only root can use "--types" option

Ideally, just as zfs create gives a human readable warning when it knows it can't mount a volume, zfs destroy should give a human readable warning when it knows it can't unmount a volume.

Describe how to reproduce the problem

$ sudo zfs allow user create,mount,destroy pool/vol
$ zfs create pool/vol/test
filesystem successfully created, but it may only be mounted by root
$ sudo zfs mount pool/vol/test
$ zfs destroy pool/vol/test
umount: only root can use "--types" option
cannot unmount '/vol/test': umount failed

Include any warning/errors/backtraces from the system logs

[fvigotti]

+1 , same problem
useful in send/receive streams over ssh to a non root user destination ( root is not allowed from remote for security )

[minorsatellite]

+1. I ran against this issue yesterday. I am assuming that this is a bug not a "feature".

[jsoref]

To be clear, this is purely about improving the error message.

The unmount restriction is from Linux itself.

And to some extent this issue is for me to hang a PR from, although I haven't gotten to it yet.

[minorsatellite]

Any workarounds on the Linux side? I would prefer not the elevate to root for ordinary replication jobs.

[jpoa]

You can use sudo as a workaround and control which datasets and actions are allowed via the sudoers file (you also need to create a user of course), works fine for me.

…

On Sat, May 25, 2019 at 1:38 AM minorsatellite ***@***.***> wrote: Any workarounds on the Linux side? I would prefer not the elevate to root for ordinary replication jobs. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8478>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIQO7F4NR6ZJAYB7DYDI7LPXB4BDANCNFSM4G4HCNMQ> .

[jsoref]

@minorsatellite: with many many many security warnings, apparently there would be some way to work around this using setcap cap_sys_admin+ep /sbin/mount.zfs per #8817 (comment) -- hand waving on my part: while I'm vaguely aware of caps, I have not done much with them -- before doing this, you should read about caps and get a sense of the security implications.

[bghira]

it's probably fixed in 0.8.

[stuartthebruce]

it's probably fixed in 0.8.

Not for me,

[zfs.backup@vsm-nfs1 ~]$ rpm -q zfs
zfs-0.8.5-1.el7.x86_64

[zfs.backup@vsm-nfs1 ~]$ zfs allow cit-backup
---- Permissions on cit-backup ---------------------------------------
Local+Descendent permissions:
        user zfs.backup compression,create,destroy,mount,receive,rollback

[zfs.backup@vsm-nfs1 ~]$  zfs destroy cit-backup/home1/duncan.macleod
umount: only root can use "--types" option
cannot unmount '/cit-backup/home1/duncan.macleod': umount failed

[johnknl]

This is broken in 0.8.3-1ubuntu12.12

[stale]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

[jsoref]

Sigh

[stale]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

[jsoref]

Sigh