On Thu, Aug 06, 2009 at 07:39:34AM -0600, Rob Thurlow wrote:
> Mike Mackovitch wrote:
>
> >(1) Attempts to request the FATTR4_NAMED_ATTR attribute on the ".zfs"
> >directory and any immediate subdirectories causes the GETATTR operation
> >to return NFS4ERR_INVAL. The same GETATTR operation with that attribute
> >ommitted succeeds. Seeing as how this attribute is technically a
> >"mandatory" attribute... I don't think EINVAL is a fair response. :-)
> >If the attribute is not supported on those directories, I would suggest
> >simply not returning that attribute.
> >
> >(2) ACCESS operations on the ".zfs/snapshot" directory and the snapshot
> >subdirectories erroneously report that the user is not allowed to create
> >or delete snapshot directories even though the user does have the
> >permissions to perform those operations - and performing such operations
> >succeeds. This happens for a normal user that has delegated authority to
> >perform those operations and also for the root user when root is mapped
> >to root on the server. (This also affects NFSv3.)
>
> Hi Mike,
>
> I think you're right on both counts, and will investigate.
> I've created this OpenSolaris bug:
>
> 6869153 Problems reported with NFSv4 access to .zfs
>
> When it percolates through the system, you should be able
> to track it with this link:
>
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6869153
Thanks Rob.
I imagine the two issues might be different enough that you may want
to separate it into two bugs.
Regarding the ACCESS issue: it affects both NFSv4 and NFSv3.
Also, it appears that even when performed directly on the ZFS file
system on the server, access(2) calls on the snapshot directory always
return no WRITE access ("Permission Denied"). So, the issue likely
lies deeper than the NFS server code.
(Of course, one could argue that the issue there is with the NFS
client('s VFS layer) using ACCESS to first check if it should attempt
an operation instead of just attempting the operation.)
Thanks again.
--macko
