I noticed an issue that was not fixed by #419. When in forensics mode and using running cryptsetup open <file> cdev, cdev will not always have the expected/desired ro/rw status.
What should happen is, if cdev is marked RO if and only if file is on a RO mounted filesystem. Ideally, cdev should be set to RO if the file does not have write permissions, but let's tackle that another day.
What actually happens is that cdev can be set as RO even if file is on a RW mounted filesystem depending on the RO/RW state of the loop device that is chosen. #419 explicitly handles loop devices, however, that code is unlikely to get run. The reason is that the script does not get run when a loop device's backing device changes. This shows up as a udev change event. The script only gets run on udev change events that remove RO from a block device (see /lib/udev/rules.d/01-grml-forensic.rules) or udev block add events.
As mentioned in #419, loop devices are usually persistent and so is their RW/RO state. So if a loop device was previously marked as RO, but then the backing file gets changed to a file that should have the loop device be RW, the loop device won't get set to RW because the script won't be run.
When adding the rule ACTION=="change", SUBSYSTEM=="block", KERNEL=="loop[0-9]*", RUN+="/etc/udev/scripts/forensic-mark-readonly $name", the script does get run on loop device backing file change. However, what's odd is that the loop device udev change events come after the udev block add for the dm-crypt device. This means that while the loop device gets set to RW, the dm-crypt device is still RO. So a way to change a dm-crypt device from RO to RW needs to be found. Perhaps reloading the DM table will work, but its currently untested.
NOTE: I believe that I forgot to add this change to #419. But from current testing, as noted above, that wouldn't be enough to fi this issue. However, it would fix a similar issue when changing the loop device directly with losetup.
I noticed an issue that was not fixed by #419. When in forensics mode and using running
cryptsetup open <file> cdev,cdevwill not always have the expected/desired ro/rw status.What should happen is, if
cdevis marked RO if and only iffileis on a RO mounted filesystem. Ideally,cdevshould be set to RO if the file does not have write permissions, but let's tackle that another day.What actually happens is that
cdevcan be set as RO even iffileis on a RW mounted filesystem depending on the RO/RW state of the loop device that is chosen. #419 explicitly handles loop devices, however, that code is unlikely to get run. The reason is that the script does not get run when a loop device's backing device changes. This shows up as a udev change event. The script only gets run on udev change events that remove RO from a block device (see/lib/udev/rules.d/01-grml-forensic.rules) or udev block add events.As mentioned in #419, loop devices are usually persistent and so is their RW/RO state. So if a loop device was previously marked as RO, but then the backing file gets changed to a file that should have the loop device be RW, the loop device won't get set to RW because the script won't be run.
When adding the rule
ACTION=="change", SUBSYSTEM=="block", KERNEL=="loop[0-9]*", RUN+="/etc/udev/scripts/forensic-mark-readonly $name", the script does get run on loop device backing file change. However, what's odd is that the loop device udev change events come after the udev block add for the dm-crypt device. This means that while the loop device gets set to RW, the dm-crypt device is still RO. So a way to change a dm-crypt device from RO to RW needs to be found. Perhaps reloading the DM table will work, but its currently untested.NOTE: I believe that I forgot to add this change to #419. But from current testing, as noted above, that wouldn't be enough to fi this issue. However, it would fix a similar issue when changing the loop device directly with
losetup.