linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: "btrfs: harden agaist duplicate fsid" spams syslog
Date: Fri, 12 Jul 2019 01:06:34 +0200	[thread overview]
Message-ID: <e483092adc63d3d86cb99c8e4dcbd56f1d1539b8.camel@scientia.net> (raw)
In-Reply-To: <c01ab9f6-c553-3625-5656-a8f61659de7d@oracle.com>

I'm also seeing these since quite a while on Debian sid:

Jul 11 13:33:56 heisenberg kernel: BTRFS info (device dm-0): device fsid 60[...]3c devid 1 moved old:/dev/mapper/system new:/dev/dm-0
Jul 11 13:33:56 heisenberg kernel: BTRFS info (device dm-0): device fsid 60[...]3c devid 1 moved old:/dev/dm-0 new:/dev/mapper/system
Jul 11 23:43:35 heisenberg kernel: BTRFS info (device dm-0): device fsid 60[...]3c devid 1 moved old:/dev/mapper/system new:/dev/dm-0
Jul 11 23:43:35 heisenberg kernel: BTRFS info (device dm-0): device fsid 60[...]3c devid 1 moved old:/dev/dm-0 new:/dev/mapper/system

In my case it's a simply dm-crypt layer below the fs.


Some years ago, there was a longer thread on this list about the
fragility of btrfs with respect to accidentally or intentionally
colliding UUIDs.
IIRC there were quite some concerns that this could have even a big
security impact when an attacker e.g. plugs in a device with a certain
UUID and the kernel or userland automatically adds or somehow else uses
such device (just by UUID).
Back then it was said this would be looked into... has anything
happened there?


Cheers,
Chris.


  parent reply	other threads:[~2019-07-11 23:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10 18:49 "btrfs: harden agaist duplicate fsid" spams syslog Graham Cobb
2019-07-11  2:46 ` Anand Jain
2019-07-11 18:00   ` Graham Cobb
2019-07-12 12:46     ` Anand Jain
2019-07-12 13:32       ` Graham Cobb
2019-07-19 15:38         ` David Sterba
2019-07-12 13:35       ` Patrik Lundquist
2019-07-12 13:41         ` Graham Cobb
2019-07-11 23:06   ` Christoph Anton Mitterer [this message]
2019-07-12 12:49     ` Anand Jain
2019-07-16 13:59 ` [PATCH] btrfs: ratelimit device path change info on mounted device Anand Jain
2019-07-16 14:08   ` Anand Jain
2019-07-19 14:58   ` David Sterba

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=e483092adc63d3d86cb99c8e4dcbd56f1d1539b8.camel@scientia.net \
    --to=calestyo@scientia.net \
    --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).