linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Tobias Geerinckx-Rice <tobias.geerinckx.rice@gmail.com>
Cc: <kreijack@inwind.it>, <linux-btrfs@vger.kernel.org>
Subject: Re: [RFC PATCH] Revert "btrfs: allow mounting btrfs subvolumes with different ro/rw options"
Date: Thu, 3 Jul 2014 16:33:36 +0800	[thread overview]
Message-ID: <53B51560.2040603@cn.fujitsu.com> (raw)
In-Reply-To: <CAKFHe2T3FaXcO2k8NQoLx2x_xyep903hTnNRdOE62uEf+iu42Q@mail.gmail.com>


-------- Original Message --------
Subject: Re: [RFC PATCH] Revert "btrfs: allow mounting btrfs subvolumes 
with different ro/rw options"
From: Tobias Geerinckx-Rice <tobias.geerinckx.rice@gmail.com>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Date: 2014年07月03日 16:06
> [List CCd. I hate Gmail.]
>
> Noob alert.
>
> On 3 July 2014 02:28, Qu Wenruo <quwenruo@cn.fujitsu.com> wrote:
>> Subject: Re: [RFC PATCH] Revert "btrfs: allow mounting btrfs subvolumes w=
> ith
>> different ro/rw options"
>> From: Goffredo Baroncelli <kreijack@libero.it>
>> To: Qu Wenruo <quwenruo@cn.fujitsu.com>, linux-btrfs@vger.kernel.org
>> Date: 2014=E5=B9=B407=E6=9C=8803=E6=97=A5 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,r=
> w
>>> 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 noth=
> ing
>> 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.
> This assumption seems wrong and untenable if considered from a
> different angle: one doesn't mount the "whole disk" ro, merely the
> default subvolume.
>
> # mount -o ro /dev/sda1 /mnt
>
> is merely convenient short-hand for
>
> # mount -o ro,subvol=3D@ [or whatever] /dev/sda1 /mnt
>
> and anyone who expects this to magically protect the whole disk is,
> frankly, confused.
>
> Substituting partitions for subvolumes: mounting /dev/sda2 read-only
> should have no effect on /dev/sda3.
> Even if you went a bit batty and decided to make /dev/sda2 the
> "default partition":
>
> # ln -sf /dev/sda2 /dev/sda
> # mount -o ro /dev/sda /mnt/this/is/silly
>
> syntactic sugar doesn't change anything.
>
> Subvolumes are logically discrete entities, the fact that they share
> trees on-disk is merely a (very nice) implementation detail. It is
> impossible to mount a "whole disk" under btrfs.
Oh, sorry for my confusing words.
To make it clear, when mentioning 'the whole disk(or partition 
whatever)' I mean the FS_TREE.
(Of course not the default subvolume)

The problem is that, even you mount a subvolume ro, you can still change 
contents in the subvolume
through its rw parent subvolume.
And if a subvolume can still be modified, the ro mount lose it meaning.

So we need special rules to prevent such things.

Thanks,
Qu
>
> Tobias
>
>> The problem also happens when a parent subvol is mounted rw but child sub=
> vol
>> is mounted ro.
>> User can still modify the child subvol through parent subvol, still broke
>> the readonly rule.
> This makes sense, though.


  reply	other threads:[~2014-07-03  8:32 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 [this message]
2014-07-03 11:26         ` Tobias Geerinckx-Rice
2014-07-03 17:37     ` Goffredo Baroncelli
2014-07-04  1:28       ` Qu Wenruo
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=53B51560.2040603@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=tobias.geerinckx.rice@gmail.com \
    /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).