Bug 1130860

Summary: btrfs: cannot mount subvolume with selinux context
Product: Red Hat Enterprise Linux 7 Reporter: Eryu Guan <eguan>
Component: kernelAssignee: fs-maint
kernel sub component: Btrfs QA Contact: Filesystem QE <fs-qe>
Status: CLOSED CURRENTRELEASE Docs Contact:
Severity: medium    
Priority: medium CC: esandeen, xuw, zab
Version: 7.0   
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-22 08:49:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Eryu Guan 2014-08-18 04:54:48 UTC 
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:
Comment 1 Eryu Guan 2014-08-18 05:07:26 UTC 
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.
Comment 2 Zach Brown 2014-08-18 19:26:35 UTC 
> 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.
Comment 5 XuWang 2015-04-22 08:49:07 UTC 
notice the commit"
commit 41cdfbb7ac0da38aa55d6bef9f54798a4c3d66a6
Author: Eric Sandeen <sandeen>
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.