All of lore.kernel.org
 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 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.