All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz, "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC] btrfs: harden agaist duplicate fsid
Date: Tue, 13 Nov 2018 23:47:23 +0800	[thread overview]
Message-ID: <228b66c4-f85c-11dc-1a24-d46bc5493788@oracle.com> (raw)
In-Reply-To: <20181113153149.GD24115@twin.jikos.cz>



On 11/13/2018 11:31 PM, David Sterba wrote:
> On Mon, Oct 01, 2018 at 09:31:04PM +0800, Anand Jain wrote:
>>>> +        /*
>>>> +         * we are going to replace the device path, make sure its the
>>>> +         * same device if the device mounted
>>>> +         */
>>>> +        if (device->bdev) {
>>>> +            struct block_device *path_bdev;
>>>> +
>>>> +            path_bdev = lookup_bdev(path);
>>>> +            if (IS_ERR(path_bdev)) {
>>>> +                mutex_unlock(&fs_devices->device_list_mutex);
>>>> +                return ERR_CAST(path_bdev);
>>>> +            }
>>>> +
>>>> +            if (device->bdev != path_bdev) {
>>>> +                bdput(path_bdev);
>>>> +                mutex_unlock(&fs_devices->device_list_mutex);
>>>> +                return ERR_PTR(-EEXIST);
>>> It would be _really_ nice to have an informative error message printed
>>> here.  Aside from the possibility of an admin accidentally making a
>>> block-level copy of the volume,
>>
>>> this code triggering could represent an
>>> attempted attack against the system, so it's arguably something that
>>> should be reported as happening.
>>
>>>    Personally, I think a WARN_ON_ONCE for
>>> this would make sense, ideally per-volume if possible.
>>
>>    Ah. Will add an warn. Thanks, Anand
> 
> The requested error message is not in the patch you posted or I have
> missed that (https://patchwork.kernel.org/patch/10641041/) .

  No you didn't miss. I missed it. When you integrated this into
  for-next, I should have sent out v2. Sorry. Thanks for taking
  care of it.

> Austin, is the following ok for you?
> 
>    "BTRFS: duplicate device fsid:devid for %pU:%llu old:%s new:%s\n"
> 
>    BTRFS: duplicate device fsid:devid 7c667b96-59eb-43ad-9ae9-c878f6ad51d8:2 old:/dev/sda6 new:/dev/sdb6
> 
> As the UUID and paths are long I tried to squeeeze the rest so it's
> still comprehensible but this would be better confirmed. Thanks.

Thanks, Anand



  parent reply	other threads:[~2018-11-13 15:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-01  8:56 [PATCH RFC] btrfs: harden agaist duplicate fsid Anand Jain
2018-10-01 11:17 ` Austin S. Hemmelgarn
2018-10-01 13:31   ` Anand Jain
2018-11-13 15:31     ` David Sterba
2018-11-13 15:40       ` Austin S. Hemmelgarn
2018-11-13 15:47       ` Anand Jain [this message]
2018-11-15  2:59         ` Anand Jain

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=228b66c4-f85c-11dc-1a24-d46bc5493788@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=ahferroin7@gmail.com \
    --cc=dsterba@suse.cz \
    --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 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.