Hide Forgot
Description of problem: mount btrfs with selinux context, then create a subvolume, the new subvolume cannot be mounted, even with the same context. 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 The last mount fails, and dmesg shows: SELinux: mount invalid. Same superblock, different security settings for (dev sda5, type btrfs) But in fact, the security settings are the same. Version-Release number of selected component (if applicable): kernel-3.10.0-128.el7 upstream kernel also has this issue, I tested on 3.16-rc4 How reproducible: always Steps to Reproduce: 1. see description 2. 3. Actual results: subvolume cannot be mounted Expected results: subvolume can be mounted with the same selinux context Additional info:
In fs/super.c struct dentry * mount_fs(struct file_system_type *type, int flags, const char *name, void *data) { struct dentry *root; struct super_block *sb; char *secdata = NULL; int error = -ENOMEM; if (data && !(type->fs_flags & FS_BINARY_MOUNTDATA)) { secdata = alloc_secdata(); if (!secdata) goto out; error = security_sb_copy_data(data, secdata); if (error) goto out_free_secdata; } root = type->mount(type, flags, name, data); The security_sb_copy_data() takes out selinux context data to "secdata", then mount_subvol() calls mount_fs() (via vfs_kern_mount()) again without selinux context, so mount_subvol() fails, which fails the whole mount.
> The security_sb_copy_data() takes out selinux context data to "secdata", > then mount_subvol() calls mount_fs() (via vfs_kern_mount()) again without > selinux context, so mount_subvol() fails, which fails the whole mount. That certainly looks plausible. I think btrfs is relatively unique in calling vfs_kern_mount() from ->mount(). This should be reported upstream to see how they want to handle it. The fix will probably be to rework the vfs functions a bit so that btrfs doesn't call such a high level mount function from within mount processing.
notice the commit" commit 41cdfbb7ac0da38aa55d6bef9f54798a4c3d66a6 Author: Eric Sandeen <sandeen@redhat.com> Date: Thu Mar 26 16:47:25 2015 -0400 [fs] btrfs: Make btrfs handle security mount options internally to avoid losing security label " solved this problem. Also run xfsttest, seems good. The xfstest btrfs/075 result is like below: Running test btrfs/075 #! /bin/bash # FSQA Test No. btrfs/075 # # If one subvolume was mounted with selinux context, other subvolumes # should be able to be mounted with the same selinux context too. # #----------------------------------------------------------------------- # Copyright (C) 2014 Red Hat Inc. All rights reserved. # # This program is free software; you can redistribute it and/or FSTYP -- btrfs PLATFORM -- Linux/x86_64 sgi-xe310-03 3.10.0-238.el7.x86_64 MKFS_OPTIONS -- /dev/sda3 MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/sda3 /mnt/xfstests/mnt2 btrfs/075 0s Ran: btrfs/075 Passed all 1 tests So I think I can set this bug to be verifed.