From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Joe Thornber <thornber@redhat.com>
Cc: "Alasdair Kergon" <agk@redhat.com>,
"Mike Snitzer" <snitzer@kernel.org>,
dm-devel@redhat.com,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
linux-kernel@vger.kernel.org
Subject: Re: [dm-devel] [PATCH 1/2] Fail I/O to thin pool devices
Date: Tue, 7 Feb 2023 11:19:19 -0500 [thread overview]
Message-ID: <Y+J6CgDVnBlW3pO+@itl-email> (raw)
In-Reply-To: <CAJ0trDZsTcD43s3GQ7aKR_3eABWv0rREMrajw8xBQiu96X+B8w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]
On Tue, Feb 07, 2023 at 03:02:51PM +0000, Joe Thornber wrote:
> Nack.
>
> I don't see the security issue; how is this any different from running the
> thin tools on any incorrect device? Or even the data device that the pool
> is mirroring.
I special-cased the pool device for two reasons:
1. I have run the thin tools on the pool device myself before realising
that they needed to be run on the metadata device. It took me a
while to realize that I was using the wrong device. I have not made
that mistake with other devices, which is why I special-cased the
pool device in this patch.
2. Doing I/O to the pool device is pointless. The pool device is
strictly slower than the data device and exposes the exact same
contents, so accessing the pool device directly is never what one
wants.
If there are backwards compatibility concerns, I could make this be
controlled by a Kconfig option, module parameter, or both.
> In general the thin tools don't modify the metadata they're
> running on. If you know of a security issue with the thin tools please let
> me know.
I am not aware of a concrete security problem, but in general I prefer
not to expose unnecessary attack surface.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-02-07 16:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 1:18 Demi Marie Obenour
2023-02-07 1:18 ` [PATCH 2/2] dm-thin: Allow specifying an offset Demi Marie Obenour
[not found] ` <CAJ0trDZ88Tcaf9Y75S-vB1vWXPN9UEsqPV1bTrkAtSYFfUngAQ@mail.gmail.com>
2023-02-07 16:24 ` [dm-devel] " Demi Marie Obenour
[not found] ` <CAJ0trDZsTcD43s3GQ7aKR_3eABWv0rREMrajw8xBQiu96X+B8w@mail.gmail.com>
2023-02-07 16:19 ` Demi Marie Obenour [this message]
2023-02-07 17:50 ` [dm-devel] [PATCH 1/2] Fail I/O to thin pool devices Zdenek Kabelac
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=Y+J6CgDVnBlW3pO+@itl-email \
--to=demi@invisiblethingslab.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marmarek@invisiblethingslab.com \
--cc=snitzer@kernel.org \
--cc=thornber@redhat.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
all inboxes | Powered by JetHome®