linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: <kreijack@inwind.it>, <linux-btrfs@vger.kernel.org>
Subject: Re: [RFC PATCH] Revert "btrfs: allow mounting btrfs subvolumes with different ro/rw options"
Date: Fri, 4 Jul 2014 09:28:13 +0800	[thread overview]
Message-ID: <53B6032D.6090207@cn.fujitsu.com> (raw)
In-Reply-To: <53B594E7.9070500@inwind.it>


-------- Original Message --------
Subject: Re: [RFC PATCH] Revert "btrfs: allow mounting btrfs subvolumes 
with different ro/rw options"
From: Goffredo Baroncelli <kreijack@inwind.it>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>, linux-btrfs@vger.kernel.org
Date: 2014年07月04日 01:37
> On 07/03/2014 02:28 AM, Qu Wenruo wrote:
>> -------- Original Message --------
>> Subject: Re: [RFC PATCH] Revert "btrfs: allow mounting btrfs subvolumes with different ro/rw options"
>> From: Goffredo Baroncelli <kreijack@libero.it>
>> To: Qu Wenruo <quwenruo@cn.fujitsu.com>, linux-btrfs@vger.kernel.org
>> Date: 2014年07月03日 01:48
>>> On 07/01/2014 11:30 AM, Qu Wenruo wrote:
>>>> This commit has the following problem:
>>>> 1) Break the ro mount rule.
>>>> When users mount the whole btrfs ro, it is still possible to mount
>>>> subvol rw and change the contents. Which make the whole fs ro mount
>>>> non-sense.
>>> Where is the problem ? I see an use case when I want a conservative default: mount all ro except some subvolumes.
>>>
>>> In any case it is not a security problem because if the user has the capability to mount a subvolume, also he has the capability to remount,rw the whole filesystem.
>>>
>>>
>>>
>> Not security problem but behavior not consistent.
>> If user mount the whole disk ro, he or she want the fs read only and nothing will change in it.
>> If you mount a subvol rw, then the whole disk ro expectation is broken. Things will change even the whole
>> disk is readonly.
> Sorry for bother you again, but there is a thing not clear to me:
>
> If
>
>      # mount -o subvolid=5,ro /dev/sda1 /mnt/root
>      # mount -o subvol=subvolname,rw /dev/sda1 /mnt/subvolname
>
> I suppose that
>
>      # touch /mnt/root/touch-test 		# 1
>
> fails, and
>
>      # touch /mnt/subvolname/touch-test		# 2
>
> succeeded. I understood correctly ?
Your understanding is right and that is current behavior.

But that should not be the correct behavior.

If you mount fs_tree ro, btrfs should ensure the whole fs_tree(including 
all the subvolumes) ro.
Or the whole fs_tree is not restricted readonly since you can modify 
contents inside the rw subvolume,
and it's part of the fs_tree.(partly ro and partly rw status)

IMO the perfect logical should be like the following:
1) ro mounted subvolume will force all the children subvolumes only ro 
mountable

subvol 5 (mounted ro /)
├── subvol 257 (mounted rw /mnt/btrfrs)
So above mounted should not be allowed.

But the following mount should be OK:
subvol 5 (mounted rw /)
├── subvol 257 (mounted ro /mnt/btrfrs)

2) ro mounted subvolume will not be modified even through the rw mounted 
parent subvolume.

Only this will ensure restricted ro mount option.

If anyone has any other ideas about it, I'm happy to listen.

Thanks,
Qu
>   If so this behaviour seems to me correctly.
> Different is after mounting the subvolume "subvolumename", also the whole filesystem results rw (eg: #1 succeeded).
>
> G.Baroncelli
>
>
>
>
>
>> The problem also happens when a parent subvol is mounted rw but child subvol is mounted ro.
>> User can still modify the child subvol through parent subvol, still broke the readonly rule.
>>
>> Thanks,
>> Qu
>>
>


  reply	other threads:[~2014-07-04  1:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-01  9:30 [RFC PATCH] Revert "btrfs: allow mounting btrfs subvolumes with different ro/rw options" Qu Wenruo
2014-07-01 15:32 ` David Sterba
2014-07-01 16:36   ` Chris Mason
2014-07-02  7:59     ` Harald Hoyer
2014-07-02  8:28       ` Duncan
2014-07-02  8:58       ` Qu Wenruo
2014-07-03  1:26       ` Chris Mason
2014-07-02 17:48 ` Goffredo Baroncelli
2014-07-03  0:28   ` Qu Wenruo
2014-07-03  8:06     ` Tobias Geerinckx-Rice
2014-07-03  8:33       ` Qu Wenruo
2014-07-03 11:26         ` Tobias Geerinckx-Rice
2014-07-03 17:37     ` Goffredo Baroncelli
2014-07-04  1:28       ` Qu Wenruo [this message]
2014-07-04 17:41         ` Goffredo Baroncelli
2014-07-07  1:46           ` Qu Wenruo
2014-07-07 17:37             ` Goffredo Baroncelli
2014-07-08  2:43               ` Duncan
2014-07-08  4:07                 ` Goffredo Baroncelli

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=53B6032D.6090207@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).