linux-kernel - Re: [Patch v2] block: revert block

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 16 Feb 2011 16:46:02 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Chuck Ebbert <cebbert@...hat.com>, linux-kernel@...r.kernel.org,
	Milan Broz <mbroz@...hat.com>
Subject: Re: [Patch v2] block: revert block_dev read-only check

On Wed, Feb 16, 2011 at 4:23 PM, Tejun Heo <tj@...nel.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
seriously.

BUT.

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.

                         Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/