Dne 07. 02. 23 v 17:19 Demi Marie Obenour napsal(a):
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.
lvm2 introduced 'protection' layer device - which keeps -tpool opened and
thus avoid possibility to use i.e. mkfs on thin-pool itself (as it requires
exclusive open)
Zdenek
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
