On Aug 7, 2009, at 6:29 PM, Jeff A. Smith wrote:
> in .zfs/snapshot). Very cool that the client can create/destroy
> snapshots on the server this way.
>
> Time to dig a little deeper.
Hi Mike,
I think I've found the access issue: zfsctl_common_access()
from (uts/common/fs/zfs/zfs_ctldir.c) doesn't return write
access and doesn't check for zfs deleg admin. This code is
used as the access vop for .zfs and .zfs/snapshot:
/*
* Common access routine. Disallow writes.
*/
/* ARGSUSED */
static int
zfsctl_common_access(vnode_t *vp, int mode, int flags, cred_t *cr,
caller_context_t *ct)
{
if (flags & V_ACE_MASK) {
if (mode & ACE_ALL_WRITE_PERMS)
return (EACCES);
} else {
if (mode & VWRITE)
return (EACCES);
}
return (0);
}
Other interesting vops like mkdir/rmdir/rename have callouts
to zfs_secpolicy_[snapshot|destroy|rename]_perms() which check
for zfs delegated admin. This looks like a zfs bug. It seems
like write access should be reported if the user has one or more
of these deleg perms:
ZFS_DELEG_PERM_CREATE
_DESTROY
_MOUNT
_SNAPSHOT
_CLONE
If I'm not out in left field (again!), then this problem is a
bug/oversight in ZFS.
Jeff
Jeff
