aboutsummaryrefslogtreecommitdiffstats
path: root/cmd/zfs
diff options
context:
space:
mode:
authorMartin Matuska <[email protected]>2011-07-26 13:08:02 -0700
committerBrian Behlendorf <[email protected]>2011-08-01 12:09:11 -0700
commitca5252204aa25f81e9f19084917e0a46fdd470b0 (patch)
tree6a4b998b3df18ac80d16d9fbf1a62039f81084c0 /cmd/zfs
parent3e31d2b080b4e6665a93691d171a13d7e29a768a (diff)
Illumos #1043: Recursive zfs snapshot destroy fails
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 <[email protected]> Issue #340
Diffstat (limited to 'cmd/zfs')
0 files changed, 0 insertions, 0 deletions