Bug 1130860 - btrfs: cannot mount subvolume with selinux context
Summary: btrfs: cannot mount subvolume with selinux context
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: fs-maint
QA Contact: Filesystem QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-18 04:54 UTC by Eryu Guan
Modified: 2015-04-23 15:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-22 08:49:07 UTC


Attachments (Terms of Use)

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@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.


Note You need to log in before you can comment on or make changes to this bug.