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
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.
On Sat, Apr 4, 2015 at 5:36 AM, Daniel J Walsh dwalsh@redhat.com wrote:
It is supposed to fail.
Ok thanks. So at the moment this makes btrfs receive and Samba incompatible on the same volume. Mounting different subvolumes with different -o context= values of course doesn't work, while subvolumes are separate fs trees they still share a superblock. SELinux: mount invalid. Same superblock, different security settings for (dev sdd1, type btrfs)
Is there a way to avoid using mount -o context? What about chcon -Rt samba_share_t on the subvolume that will be Samba shared, leaving other subvolumes with default labeling for btrfs receive?
On 04/04/2015 04:27 PM, Chris Murphy wrote:
On Sat, Apr 4, 2015 at 5:36 AM, Daniel J Walsh dwalsh@redhat.com wrote:
It is supposed to fail.
Ok thanks. So at the moment this makes btrfs receive and Samba incompatible on the same volume. Mounting different subvolumes with different -o context= values of course doesn't work, while subvolumes are separate fs trees they still share a superblock. SELinux: mount invalid. Same superblock, different security settings for (dev sdd1, type btrfs)
Is there a way to avoid using mount -o context? What about chcon -Rt samba_share_t on the subvolume that will be Samba shared, leaving other subvolumes with default labeling for btrfs receive?
That should work.
selinux@lists.fedoraproject.org