Hi,
On 02/11/2013 10:41 PM, J. Bruce Fields wrote:
On Mon, Feb 11, 2013 at 04:01:33PM -0500, J. Bruce Fields wrote:
That shouldn't matter (assuming it's not actually owned by "nobody" on
the server.)
Beats me. The network trace does indeed seem to show a succesful create
(and a preceding access op that allows access that I would have expected
to fail).
I don't see how that could have happened--the server doesn't actually
enforce the ACL itself, it depends on common vfs code for that, so
there's probably something obvious we're overlooking. You're positive
the file's being created in the same directory that you set that acl on?
--b.
we tracked the cause down to the "enhanced xfs" module from SGI
(sgi-enhancedxfs-kmp-default-2.5_2.6.32.12_0.7-sgi250rp13.sles11). With
a standard xfs module
(sgi-xfs-kmp-default-6.5.0.14_2.6.32.12_0.7-sgi12111921) or on a ext3
file systems, the server respects ACL correctly. Seems like the
enhancement went into wrong direction :) Lets file a bug against the vendor.
Cheers
Jiri Horky
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
