Illumos #1043: Recursive zfs snapshot destroy fails
authorMartin Matuska <mm@FreeBSD.org>
Tue, 26 Jul 2011 20:08:02 +0000 (13:08 -0700)
committerBrian Behlendorf <behlendorf1@llnl.gov>
Mon, 1 Aug 2011 19:09:11 +0000 (12:09 -0700)
Prior to revision 11314 if a user was recursively destroying
snapshots of a dataset the target dataset was not required to
exist.  The zfs_secpolicy_destroy_snaps() function introduced
the security check on the target dataset, so since then if the
target dataset does not exist, the recursive destroy is not
performed.  Before 11314, only a delete permission check on
the snapshot's master dataset was performed.

Steps to reproduce:
zfs create pool/a
zfs snapshot pool/a@s1
zfs destroy -r pool@s1

Therefore I suggest to fallback to the old security check, if
the target snapshot does not exist and continue with the destroy.

References to Illumos issue and patch:
- https://www.illumos.org/issues/1043
- https://www.illumos.org/attachments/217/recursive_dataset_destroy.patch

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #340

module/zfs/zfs_ioctl.c

index 693ffc0..088c64b 100644 (file)
@@ -701,6 +701,9 @@ zfs_secpolicy_destroy(zfs_cmd_t *zc, cred_t *cr)
  * and destroying snapshots requires descendent permissions, a successfull
  * check of the top level snapshot applies to snapshots of all descendent
  * datasets as well.
+ *
+ * The target snapshot may not exist when doing a recursive destroy.
+ * In this case fallback to permissions of the parent dataset.
  */
 static int
 zfs_secpolicy_destroy_snaps(zfs_cmd_t *zc, cred_t *cr)
@@ -711,6 +714,8 @@ zfs_secpolicy_destroy_snaps(zfs_cmd_t *zc, cred_t *cr)
        dsname = kmem_asprintf("%s@%s", zc->zc_name, zc->zc_value);
 
        error = zfs_secpolicy_destroy_perms(dsname, cr);
+       if (error == ENOENT)
+               error = zfs_secpolicy_destroy_perms(zc->zc_name, cr);
 
        strfree(dsname);
        return (error);