Please allow zfs receive -x mountpoint for volumes

[Bronek]

Describe the feature would like to see added to OpenZFS

Allow the -x parameter of the zfs receive to strip properties which are not applicable to the object being received, e.g. mountpoint for a volume. By definition, it's a no-op which would allow generic uses of zfs receive.

How will this feature improve OpenZFS?

Enable more generic use of zfs receive

Additional context

I have a bunch of scripts which, after careful validation of supplied parameters, enable ordinary users to perform certain ZFS sub-commands, within their respective filesystems. For example, to list objects, a user would do the following:

$ sudo zfs-list
NAME                  USED  AVAIL     REFER  MOUNTPOINT
zback/remote/gdansk    96K  11.8T       96K  /data/remote/gdansk
$ cat `which zfs-send`
#!/usr/bin/bash -e
exec zfs list -t filesystem,volume,snapshot -r zback/remote/"${SUDO_USER}"

(I removed the validation part, hopefully you get the idea)

The intended use case is to provide users with a zfs-receive which they can use like this:

zfs send -R zdata/my/data@a-snapshot | ssh myid@repository 'sudo zfs-receive data'

To that end I have created a zfs-receive script which looks something like this:

$ cat `which zfs-receive`
#!/usr/bin/bash -e
exec zfs receive -v -u zback/remote/"${SUDO_USER}"/"$1"

(again, omitted the validation part). In this script I would like to strip the mountpoint property of the received filesystem, using -x mountpoint. However this does not work if the user is sending a volume:

cannot receive new filesystem stream: property 'mountpoint' does not apply to datasets of this type

Since mountpoint does not apply to volume, this should be a no-op instead of an error.

[bghira]

you can just set -o mountpoint on recv instead.

edit: missed that this is about zvol.. but i don't think this should happen, the checks are good to have.

my replication infrastructure handles this on its own, why can't yours?

[Bronek]

my replication infrastructure handles this on its own, why can't yours?

not sure - how do you do that? In my case I have users who are trusted to a certain degree and this zfs-receive script works for them to store the data for backup purposes. However I would like to also allow them to access the filesystems they send, in which case I need to place restriction on mountpoints.

Come to think of it, I might provide an alternative script e.g. named zfs-receive-local doing:

exec zfs receive -v -x mountpoint zback/remote/"${SUDO_USER}"/"$1"

... and if that script fails (because they tried to send a volume) than no useful functionality is lost, they should have used the one with -u option anyway.

[InsanePrawn]

I am very much in favour of treating -x mountpoint as nonfatal for volumes. FWIW this has been mentioned in #11416 and #6371.

We've hit the same thing in zrepl and considered an intrincate workaround, but I see no good reason why this shouldn't be allowed by zfs receive. Since volumes don't use the mountpoint anyway AND can't have child datasets, why shouldn't we just quietly handle the -x mountpoint?
I can see that handling -o mountpoint=/something would be worth a discussion, but with -x (inherit) the user's intention is to 'get rid' of the dataset's specific property value anyway;
how is this an illegal operation for a zvol? Or more importantly: how is it a dangerous one that we need to error out on?

[bghira]

it's the same with recordsize or volblocksize. there's several properties that can't be manipulated without a hard error being returned to the caller.

[Bronek]

Conceptually, -x does not manipulate a property; it blocks it from being set in a newly received dataset.

[bghira]

however, it is technically running inherit.. which fails because it's not a supported operation for the volume type.

[bghira]

for the record 6371 was only a problem because zfs send -R didn't work correctly when some datasets are 'missing' snapshots from the parent, but that has been resolved with #11710

"inelegant workarounds" are a problem with zrepl design, not with the command line arguments in ZFS utilities.

[IvanVolosyuk]

I remember someone mentioned on the mailing list(?) that the zfs recv without -x mountpoint can be a security hazard for systems which deal with untrusted send streams (backup servers) and it will be much nicer if -x mountpoint can be specified regardless of the type of the stream (don't fail if that specified for zvol).

[InsanePrawn]

Dear @bghira,

it's the same with recordsize or volblocksize. there's several properties that can't be manipulated without a hard error being returned to the caller.

you're arguing for keeping up an arbitrary limitation on grounds of this limitation existing. Please reevaluate your position.

Why are you spending time defending this anti-feature? What's it to you? What is it protecting anyone from? Who is profiting from your objections?

As it stands, I still see no good reason we can't just handle this in the receive code.
In fact, I've opened #11864, so you can voice your concerns there, if you have any factual ones.

[bghira]

we should just remove all of the error conditions and let anything happen, then. what are they protecting anyone from?