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

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

[Pascal]

[-- Attachment #1.1: Type: text/plain, Size: 542 bytes --]

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

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).

regards, lacsaP.

[-- Attachment #1.2: Type: text/html, Size: 1037 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

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

[Zdenek Kabelac]

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

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

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

[lacsaP Patatetom]

[-- Attachment #1.1: Type: text/plain, Size: 2029 bytes --]

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@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@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
>
>

[-- Attachment #1.2: Type: text/html, Size: 2824 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

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

[lacsaP Patatetom]

[-- Attachment #1.1: Type: text/plain, Size: 2636 bytes --]

hi,

I come back to you with the memo mentioned :
https://github.com/patatetom/lvm-on-readonly-block-device
I hope that it will allow you to better understand this problem of
alteration of the disk.

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.

regards, lacsaP.

Le lun. 20 mars 2023 à 15:15, lacsaP Patatetom <patatetom@gmail.com> a
écrit :

> 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@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@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
>>
>>

[-- Attachment #1.2: Type: text/html, Size: 3821 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

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

[Zdenek Kabelac]

Dne 20. 03. 23 v 17:37 lacsaP Patatetom napsal(a):
> hi,
> 
> I come back to you with the memo mentioned : 
> https://github.com/patatetom/lvm-on-readonly-block-device 
> <https://github.com/patatetom/lvm-on-readonly-block-device>
> I hope that it will allow you to better understand this problem of alteration 
> of the disk.
> 
> 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.
> 
> regards, lacsaP.
> 
> Le lun. 20 mars 2023 à 15:15, lacsaP Patatetom <patatetom@gmail.com 

Hi

So I'm possibly finally starting to understand your problem here.

You are using your own patched kernel - where you were reverting
a32e236eb93e62a0f692e79b7c3c9636689559b9  linux kernel patch.

without likely understanding the consequences.

With kernel 6.X there is commit bdb7d420c6f6d2618d4c907cd7742c3195c425e2
modifying bio_check_ro() to return void  - so your 'reverting' patch
is no longer usable the way it's been created.


 From your github report it seems you are creating  'raid' across 3 sdb drives.

So with normal kernel - it happens to be that  'dm' drives are allowed to 
bypass any 'read-only' protection set on a device.

So when you actually creating raid LV on  loop0 & loop1 - deactivate, then you 
make loop0 & loop1  read-only, active raid LV - then you can easily call 
'mkfs' and it will normally work.

Raid device consist or  '_rimage' & '_rmeta' LV per leg - where _rmeta is 
metadata device updated with activation of raid LV.

So when your local 'revert' patch for 6.X kernel no longer works - there is no 
surprise that your  'sdbX' drives are being actually modified - since ATM  dm 
targets are allowed to bypass  read-only protection.

Since the reason for the  'bypass' (snapshot read-only activation)  was fixed 
5 years ago we should probably build some better way how to restore to 
'read-only' protection - and allow to disable it only when user requests such 
behavior due to use of old user-space tooling.

Regards

Zdenek

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

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

[lacsaP Patatetom]

Le mer. 22 mars 2023 à 15:11, Zdenek Kabelac
<zdenek.kabelac@gmail.com> a écrit :
>
> Dne 20. 03. 23 v 17:37 lacsaP Patatetom napsal(a):
> > hi,
> >
> > I come back to you with the memo mentioned :
> > https://github.com/patatetom/lvm-on-readonly-block-device
> > <https://github.com/patatetom/lvm-on-readonly-block-device>
> > I hope that it will allow you to better understand this problem of alteration
> > of the disk.
> >
> > 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.
> >
> > regards, lacsaP.
> >
> > Le lun. 20 mars 2023 à 15:15, lacsaP Patatetom <patatetom@gmail.com
>
> Hi
>
> So I'm possibly finally starting to understand your problem here.

:-)

>
> You are using your own patched kernel - where you were reverting
> a32e236eb93e62a0f692e79b7c3c9636689559b9  linux kernel patch.
>
> without likely understanding the consequences.

indeed, I did not go down in the meanders of LVM and Linux kernel, I
have neither the capacity nor the time :-(
my goal was/is to prevent any modification of a read-only configured
media and this little `return true;` was doing the job for LVM :-)

>
> With kernel 6.X there is commit bdb7d420c6f6d2618d4c907cd7742c3195c425e2
> modifying bio_check_ro() to return void  - so your 'reverting' patch
> is no longer usable the way it's been created.

yes.

>
>
>  From your github report it seems you are creating  'raid' across 3 sdb drives.

I don't do anything special at this level, it's my system (ArchLinux)
that takes care of it.
the "only" thing I introduce is the udev rule which allows to switch
devices/partitions to read-only as soon as they appear.

>
> So with normal kernel - it happens to be that  'dm' drives are allowed to
> bypass any 'read-only' protection set on a device.
>
> So when you actually creating raid LV on  loop0 & loop1 - deactivate, then you
> make loop0 & loop1  read-only, active raid LV - then you can easily call
> 'mkfs' and it will normally work.
>
> Raid device consist or  '_rimage' & '_rmeta' LV per leg - where _rmeta is
> metadata device updated with activation of raid LV.

I think indeed that only the metadatas are concerned by these
modifications but they are stored somewhere on a read-only disk and
theoretically should not be modified .

>
> So when your local 'revert' patch for 6.X kernel no longer works - there is no
> surprise that your  'sdbX' drives are being actually modified - since ATM  dm
> targets are allowed to bypass  read-only protection.
>
> Since the reason for the  'bypass' (snapshot read-only activation)  was fixed
> 5 years ago we should probably build some better way how to restore to
> 'read-only' protection - and allow to disable it only when user requests such
> behavior due to use of old user-space tooling.

that would be cool ;-)
I'm currently working around my problem with a specific configuration
of lvm.conf and the use of /dev/nbd in snapshot mode which allows an
apparent change without real change.

>
> Regards
>
> Zdenek
>

thank you for these exchanges and your work.
regards, lacsaP.

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/