Re: Btrfs send receive + Samba, ERROR: lsetxattr security.selinux= failed. Operation not supported.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



It is supposed to fail.

On 04/03/2015 04:43 PM, Chris Murphy wrote:
> Short question: Is it possible to change a file's security labeling
> while the underlying file system is mounted with -o context= ? Or is
> that supposed to fail?
>
>
> Explanation:
>
> Two separate Btrfs file systems volumes mounted at
> /brick0
> /brick1
>
> I used mount option -o context=system_u:object_r:samba_share_t:s0 and
> they're both being used by Samba just fine without problems.
>
> But then:
>
> # btrfs subvolume snapshot -r /brick0/sam840ev\:chrishome\:20150403/
> /brick0/sam840ev\:chrishome\:20150403-1/
> # btrfs send /brick0/sam840ev\:chrishome\:20150403-1/ | btrfs receive /brick1
> ERROR: lsetxattr .android
> security.selinux=unconfined_u:object_r:unlabeled_t:s0 failed.
> Operation not supported
>
> The contents of this subvolume/snapshot I'm trying to send are from a
> remote rsync -a copy from an HFS+ volume where there are no security
> labels.
>
> The problem doesn't happen if I unmount /brick1 and remount without -o
> context= (and hence also Samba sharing isn't enabled either while the
> send-receive is happening).
>
> I filed a bug thinking it might be a btrfs bug, before I tried
> remounting without this context. So the question is whether this ought
> to work or not. It's a small problem in my case, but I could see the
> inability to use btrfs send-receive between Samba mounted Btrfs
> volumes or subvolumes to be a problem. Even if I mount a subvolume
> with -o context, any subsequent subvolume for that same volume
> inherits that context even if not specified.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=96121
>
>
>
>

--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux





[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux