All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Eryu Guan <guaneryu@gmail.com>, Zach Brown <zab@zabbo.net>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: [BUG] cannot mount subvolume with selinux context
Date: Thu, 21 Aug 2014 14:48:54 +0800	[thread overview]
Message-ID: <53F59656.4090404@cn.fujitsu.com> (raw)
In-Reply-To: <20140820035742.GC3013@dhcp-13-216.nay.redhat.com>


-------- Original Message --------
Subject: Re: [BUG] cannot mount subvolume with selinux context
From: Eryu Guan <guaneryu@gmail.com>
To: Zach Brown <zab@zabbo.net>
Date: 2014年08月20日 11:57
> On Tue, Aug 19, 2014 at 10:28:54AM -0700, Zach Brown wrote:
>> On Tue, Aug 19, 2014 at 11:32:16AM +0800, Eryu Guan wrote:
>>> Hi,
>>>
>>> Description of the 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
>> Submit a xfstest?
> Sure, will do.
>
> Thanks,
> Eryu
>>> 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.
>>>
>>> Not sure what's the proper fix. Zach suggestted that the fix will
>>> probably be to rework the vfs functions a bit as he said in rh
>>> bugzilla[1].
>> Yeah, I have no idea what'd be preferred here:
>>
>>   - rework the vfs _kern_ mount api to offer one that doesn't mess with
>>     selinux mount options
>>   - add a flag to have the second _kern_ mount ignore selinux (but not
>>     MS_KERNMOUNT?)
>>   - binary data and fs selinux handling?  (like nfs)
In fact, we can just make btrfs deal with "subvol=" mount option in a 
new method.
Current, btrfs handle "subvol=" by call vfs_kern_mount again and use vfs 
level mount_subtree() to do the path
search thing.

But on the other hand, btrfs does not call vfs_kern_mount() when 
handling default subvolume or "subvolid=" mount,
so, I think we can do all the path search inside btrfs instead of reuse 
vfs level functions, and convert "subvol="
mount option to "subvolid=", which should be selinux friendly now.
(And in this method mount_subvol() should be called just before 
get_default_root()).

If I am wrong, please tell me.

BTW, it seems that if mainline kernel accept the patchset which convert 
"subvolid=" to "subvol=", it will make the
bug more seriously. :-(
Thank goddness, the successor patch uses get_path()....

Thanks,
Qu
>>
>> - z
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


      reply	other threads:[~2014-08-21  6:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-19  3:32 [BUG] cannot mount subvolume with selinux context Eryu Guan
2014-08-19 17:28 ` Zach Brown
2014-08-20  3:57   ` Eryu Guan
2014-08-21  6:48     ` Qu Wenruo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53F59656.4090404@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=guaneryu@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=zab@zabbo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.