|| ||Linus Torvalds <torvalds-AT-linux-foundation.org> |
|| ||Tejun Heo <tj-AT-kernel.org> |
|| ||Re: [Patch v2] block: revert block_dev read-only check |
|| ||Wed, 16 Feb 2011 16:46:02 -0800|
|| ||Chuck Ebbert <cebbert-AT-redhat.com>, linux-kernel-AT-vger.kernel.org,
Milan Broz <mbroz-AT-redhat.com>|
|| ||Article, Thread
On Wed, Feb 16, 2011 at 4:23 PM, Tejun Heo <firstname.lastname@example.org> wrote:
> It has been a while so the details might be a bit off but read/write
> permissions on block devices are rather weird.
> * RO block devices can be opened RW.
Well, yes and no.
If the device node is RW, then that's often the most important part.
Whether the device itself then thinks it is read-only or not is almost
totally irrelevant. The internal "bdev_read_only()" thing is very much
a secondary thing, and has nothing to do with security, and everything
to do with random block device internals. So don't take it too
Some device drivers have actually done a good job historically, and
check the RW flags at open time. The only one I know of is the
traditional floppy.c, though.
HOWEVER - even then it also checks the FMODE_NDELAY, and skips all the
checks (including for media) if that bit isn't set. Because being too
anal about it is simply _wrong_. You may need to override the RO state
of the device, and you may need to open it writably in order to do so!
Because to make things even more complicated, even if the open
succeeded, the floppy driver will then check the writable bit (that it
might have ignored at open time) for certain ioctl's.
End result: it's almost certainly wrong to think that you can stop RW
open calls based on whether the device is somehow read-only. Even on a
physically read-only device you may need to have write permissions to
do certain operations.
So quite frankly, if you want to enforce read-only, you should
probably do it at command queueing time, not at open() time. Because
at open time, you just don't know enough.
to post comments)