On 10/21/13 10:14 AM, Eric Sandeen wrote: > On 10/21/13 10:09 AM, Josef Bacik wrote: >> On Mon, Oct 21, 2013 at 10:03:10AM -0500, Eric Sandeen wrote: >>>> On 10/18/13 1:26 PM, Josef Bacik wrote: >>>>>> There was a problem with send trying to overwrite a file that wasn't >>>>>> actually >>>>>> the same. This is a test to check this particular case where receive >>>>>> fails when >>>>>> it should succeed properly. I tested this to verify it fails without my >>>>>> fix and >>>>>> passes with my fix. Thanks, >>>> >>>> 2 things - >>>> >>>> Why does the selinux context break things? That seems like a problem w/ >>>> send >>>> if it can't work on a context-mounted fs? (disabling it for now doesn't >>>> bother >>>> me, but I'm surprised that it's required). >>>> >> So it is the context that xfstests is using, not contexts itself. Xfstests >> is >> using the nfs context, and using selinux contexts intercepts all getxattr >> calls, >> so when send tries to copy the xattrs for the file it calls getxattr, and >> because we are using the nfs context it returns EOPNOTSUPP from selinux, it >> never makes it down to btrfs. When using the actual real context it works >> fine >> because it calls down into the file system. >> > > This still sounds weird. Is btrfs send trying to copy the selinux attrs > directly? > > Shouldn't they be skipped, and be left up to the receiving end to set the > selinux > xattrs (or not) per the policy for the destination?
Eh, ok, Josef pointed out that "cp -a" does exactly the same thing. So I'll retract the concern & go learn more about selinux. ;) -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
