3

I'm sure I don't understood how blockdev works.

I have mounted a flash drive and it was mapped to /dev/sdb1. Then I type in a terminal (as root):

root# blockdev --setro /dev/sdb1
root# blockdev --report

the report was:

enter image description here

as you can see, the report said that /dev/sdb1 is set to read-only (ro). But I'm still able to create files and folders in the flash drive.

What I'm missing?

2 Answers 2

2

This seems to be a issue with blockdev and the drivers used to interact with the HDDs.

excerpt - RE: Read-Only Loopback to Physical Disk

> Another option that I recently found was the 'blockdev' command. You can 
> specify that the blockdev is ro even before mounting.
>
> $ blockdev --report
> $ blockdev --setro /dev/device
>
> But my professor brought up the point - these probably depend on the 
> driver used. Maybe a driver for ntfs totally ignores the ro switch? I 
> don't totally agree that blockdev would be based on the driver, but how do
> you test whether the drive actually is in ro without writing? What if
> it fails?

Also this section is relevant:

Well, the filesystem code will (or should) go through the block layer, so using blockdev --setro should be effective. However, partitions don't seem to inherit the read-only flag! In other words, if you have a hard disk /dev/sda with a single partition /dev/sda1, you can do blockdev --setro /dev/sda but if you then do blockdev --getro /dev/sda1 you'll notice that sda1's read-only flag is not set! I haven't verified yet whether sda1 can be written to in those circumstances.

So given partitions do not appear to inherit the read/write permissions you'll likely need to use mount instead.

another excerpt

> Then the saving grace - loopback devices. Mount the partition as a file. 
> You don't need to worry about drivers, support, etc.
> To do this use losetup to create a loopback device:
>
> $ losetup -r /dev/loop1 /dev/hda1
>
> This creates a read-only loopback device  pointing to `/dev/hda1`
> Then you can mount the loopback device (read-only if you are paranoid)
>
> $ mount -o ro /dev/loop1 /media/test

> This mounts the loopback device loop1 at `/media/test`. You can then 
> traverse the directory of `/dev/hda1` just like it was mounted.

> According to the PDF document I mentioned above, doing this:
>
> $ mount -o ro,loop /dev/hda1 /media/test
1

blockdev --setro must be done before the filesystem is mounted, not after, or you need to do a remount. It says that right in the manpage. This prevents a more writes than just doing mount -o ro but it still doesn't necessarily prevent all low level writes (especially due to software bugs). Think of blockdev --setro as telling the filesystem drivers that the write protect switch/jumper on the drive is flipped (remember when drives/media actually had those) but not actually preventing writes.

mount -o ro stops users/programs from creating/changing files but the filesystem driver itself may still do things like update the last mounted date and replay the journal.

readonly loop devices (losetup -r) can be used which may be more effective but that only works when filesystem doesn't span devices.

There are linux forensic writeblocker patches that give --setro more teeth but it would still be extremely rude to change a device to readonly out from under a mounted filesystem that thinks it can write to the device. The docs for that tell you more about the issues: https://github.com/msuhanov/Linux-write-blocker

The manpage neglects to mention that --setro doesn't necessarily affect the partition devices (/dev/sdb1) when set on the whole disk device (/dev/sdb).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .