[linux-lvm] LVM and RO device/partition(s)

[lacsaP Patatetom]

thank you for this first feedback.

I am writing a memo on github and will communicate the url soon.

my question is in the context of digital investigation which does not admit
the alteration of the medium.
of course, there are combinations (/etc/lvm.conf + snap at nbd for example)
which allow in fine not to alter the media but I don't understand why a
media set in read-only mode - eg. chmod 444 + blockdev --setro set before
LVM process - is not protected against LVM modifications...

regards, lacsaP.

Le lun. 20 mars 2023 à 15:00, Zdenek Kabelac <zdenek.kabelac at gmail.com> a
écrit :

> Dne 19. 03. 23 v 11:27 Pascal napsal(a):
> > hi,
> >
> > the bio_check_ro function of the blk-core.c source file of the Linux
> kernel
> > refers to LVM :
> >
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v6.2.7#n500
> <
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v6.2.7#n500
> >
> >
> > how does LVM currently behave when faced with a device marked as
> readonly ?
> > does it automatically switch itself in readonly mode?
> >
> > according to some tests carried out in a virtual machine, it seems that
> it
> > doesn't and that LVM modifies the disk/partition(s) even though they are
> all
> > readonly (chmod 444 && blockdev --setro).
>
>
> Hi
>
> There is no extra logic around RO devices in lvm2.  When lvm2 succeeds
> opening
> device in write mode, it'll use it for writing.
>
> Also note - when you 'activate' a LV in read-write mode - someone opens
> such
> LV/device and you later on 'lvchange' such active LV to read-only mode -
> all
> writers will keep writing to such device.
>
> It's not quite clear which kind of problem you are actually hitting - so
> maybe
> adding some more descriptive  environment +  logs  might give more info
> about
> your individual case.
>
> Note: root admin typically can overwrite any 'mild' protections...
>
> Regards
>
> Zdenek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20230320/69bea5e3/attachment.htm>