On Tue, Feb 12, 2013 at 03:02:56PM +0100, Jiri Horky wrote: > 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. OK, thanks for the followup. That's extremely weird. --b. -- 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
