<div dir="ltr"><div>hi,</div><div><br></div><div>I come back to you with the memo mentioned : <a href="https://github.com/patatetom/lvm-on-readonly-block-device">https://github.com/patatetom/lvm-on-readonly-block-device</a></div><div>I hope that it will allow you to better understand this problem of alteration of the disk.</div><div><br></div><div>as I mentioned, LVM should normally/theoretically not touch the disk as long as it is read-only, but what bothers me the most is the fact that I can't "catch up" by correcting the new 6.1.15 kernel as I did before.</div><div><br></div><div>regards, lacsaP.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 20 mars 2023 à 15:15, lacsaP Patatetom <<a href="mailto:patatetom@gmail.com">patatetom@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>thank you for this first feedback.</div><div><br></div><div>I am writing a memo on github and will communicate the url soon.</div><div><br></div>my question is in the context of digital investigation which does not admit the alteration of the medium.<br><div>of course, there are combinations (/etc/lvm.conf + snap@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...</div><div><br></div><div>regards, lacsaP.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 20 mars 2023 à 15:00, Zdenek Kabelac <<a href="mailto:zdenek.kabelac@gmail.com" target="_blank">zdenek.kabelac@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dne 19. 03. 23 v 11:27 Pascal napsal(a):<br>
> hi,<br>
> <br>
> the bio_check_ro function of the blk-core.c source file of the Linux kernel <br>
> refers to LVM :<br>
> <a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v6.2.7#n500" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v6.2.7#n500</a> <<a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v6.2.7#n500" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v6.2.7#n500</a>><br>
> <br>
> how does LVM currently behave when faced with a device marked as readonly ?<br>
> does it automatically switch itself in readonly mode?<br>
> <br>
> according to some tests carried out in a virtual machine, it seems that it <br>
> doesn't and that LVM modifies the disk/partition(s) even though they are all <br>
> readonly (chmod 444 && blockdev --setro).<br>
<br>
<br>
Hi<br>
<br>
There is no extra logic around RO devices in lvm2.  When lvm2 succeeds opening <br>
device in write mode, it'll use it for writing.<br>
<br>
Also note - when you 'activate' a LV in read-write mode - someone opens such <br>
LV/device and you later on 'lvchange' such active LV to read-only mode - all <br>
writers will keep writing to such device.<br>
<br>
It's not quite clear which kind of problem you are actually hitting - so maybe <br>
adding some more descriptive  environment +  logs  might give more info about <br>
your individual case.<br>
<br>
Note: root admin typically can overwrite any 'mild' protections...<br>
<br>
Regards<br>
<br>
Zdenek<br>
<br>
</blockquote></div>
</blockquote></div>