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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Feb 2011 01:23:35 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.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

Helo,

On Wed, Feb 16, 2011 at 03:56:10PM -0800, Linus Torvalds wrote:
> > The commit was part of effort to enforce the ro flag.  It at least
> > makes sure that a device can't be opened RW if marked RO.  loop and dm
> > showed some problems but fixing the in-kernel part isn't difficult
> > (fixes pending).
> 
> Well, if the thing breaks things, then it needs to be reverted, or
> those fixes need to not be "pending".

They should be mergeable once Jens comes back.

> > IIUC, the problematic part is dm userland, which reportedly opens
> > member devices RW even when building a RO device.  The problem is when
> > a user is trying to build RO dm device from RO member devices.  dm
> > userland tries to open the member devices RW, which block layer
> > rejects now thus failing dm assembly.
> 
> .. this makes me all the more suspicious. Sounds unfixable in a single
> release (or even a few years). So it smells like we should (a) do the
> revert and (b) add a warning for the case where somebody opens a
> device RW where the low-level device itself is RO.

Yeap, I'm not against reverting.  That is likely the right thing to do
in this cycle anyway.

> That said, if the user has permission to open the device RW (and the
> normal device node permission checks have obviously always done that
> check), I do think it's perfectly ok to do that. And if the user never
> writes to it, then the fact that the device isn't writable is
> irrelevant.

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.

* Block devices can get writes whether the device is opened RO or RW.

* Filesystem journal replay and probably some of stacking block driver
  metadata updates issue writes to RO block devices.

So, IIUC, there already are paths where writes are issued and
processed where they shouldn't be.  Everything is RO but the block
device ends up being modified.

Thanks.

--
tejun
--
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/