]> git.hungrycats.org Git - linux/commit
btrfs: Make btrfs handle security mount options internally to avoid losing security...
authorQu Wenruo <quwenruo@cn.fujitsu.com>
Tue, 23 Sep 2014 05:40:08 +0000 (13:40 +0800)
committerZygo Blaxell <zblaxell@serenity.furryterror.org>
Fri, 23 Jan 2015 13:15:12 +0000 (08:15 -0500)
commitbc2d5d186f6862fabdc328c932596d244d33bd8b
tree00e4902c60701ed0b612a21d0ff84f6ad40e5ad0
parent1aa968095913a26629055e8aa5a911905380abc9
btrfs: Make btrfs handle security mount options internally to avoid losing security label.

[BUG]
Originally when mount btrfs with "-o subvol=" mount option, btrfs will
lose all security lable.
And if the btrfs fs is mounted somewhere else, due to the lost of
security lable, SELinux will refuse to mount since the same super block
is being mounted using different security lable.

[REPRODUCER]
With SELinux enabled:
 #mkfs -t btrfs /dev/sda5
 #mount -o context=system_u:object_r:nfs_t:s0 /dev/sda5 /mnt/btrfs
 #btrfs subvolume create /mnt/btrfs/subvol
 #mount -o subvol=subvol,context=system_u:object_r:nfs_t:s0 /dev/sda5
  /mnt/test

kernel message:
SELinux: mount invalid.  Same superblock, different security settings
for (dev sda5, type btrfs)

[REASON]
This happens because btrfs will call vfs_kern_mount() and then
mount_subtree() to handle subvolume name lookup.
First mount will cut off all the security lables and when it comes to
the second vfs_kern_mount(), it has no security label now.

[FIX]
This patch will makes btrfs behavior much more like nfs,
which has the type flag FS_BINARY_MOUNTDATA,
making btrfs handles the security label internally.
So security label will be set in the real mount time and won't lose
label when use with "subvol=" mount option.

Reported-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: Chris Mason <clm@fb.com>
(cherry picked from commit f667aef6af626d0cdce0204bc7a2888e62076525)
fs/btrfs/ctree.h
fs/btrfs/super.c