On Fri, Aug 07, 2009 at 06:29:43PM -0500, Jeff A. Smith wrote: > > On Aug 7, 2009, at 6:03 PM, Jeff A. Smith wrote: > > > >file creation/rename/removal. I don't expect that ZFS > >will ever allow the normal/posix operations to modify .zfs or > >any of its immediate subdirs. I suspect that this is the > > > > > Oops. Just as a lark, I tried dir operations in a .snapshot > dir and had my expectations destroyed. I hadn't used that
Hi Jeff, I'm glad you found that on your own... I'm not sure how fun it would be for me to try to convince you that it should work. :-) BTW, I (mostly*) understand what the whole ".zfs" thing is. And I understand your initial reasoning.... it makes sense. (* The part I don't quite understand was that I expected the snapshot directories to appear as separate file systems but they are not. I even had put off trying to access them from my NFS client until I had some "mirror mount" support in place. Then I discovered I didn't need it. *My* expectations were destroyed there.) On Fri, Aug 07, 2009 at 07:04:32PM -0500, Jeff A. Smith wrote: > > 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. > > 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: > > [...] > > 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. That sounds about right. BTW, to pick a nit, it's not just about delegated administration. Even the root user calling ACCESS gets the wrong answer. root/superuser/uid=0 gets the write access even without a delegation. Not calling zfs_secpolicy_* explains both the root and delegated user cases. Thanks for tracking this down.... and sorry about what happened to your expectations. ;-) Hopefully the ZFS folks can get this fixed. (and I'd imagine you'd want to file a separate bug for that) Thanks. --macko
