On Fri, Aug 3, 2018 at 12:18 PM Zdenek Kabelac <zkabelac@xxxxxxxxxx> wrote:
>
> From my userland POV - leaving kernel write to devices that are supposed to
> be read-only 'just because' it's kernel is wrong - the fact it has NOT been
> discover for so long means - there are not many users and not many testers of
> this combination.
Sure. But at the same time, the "read-only" issue from a _security_
standpoint should never be about some device state.
Why? Because the Unix security rules aren't about "read-only devices".
They are about permissions, and if you don't want your users to have
write permissions to a device, then they shouldn't have those
permissions.
So the "set_disk_ro()" interface is simply not for security. Anybody
who uses it for security is seriously confused.
No, the "set_disk_ro()" interface is so that you can say "you
physically cannot write to this medium". It's meant for things like
CD-ROM devices, or for a floppy device when you notice that the
controller reports that the floppy itself is physically
write-protected.
THAT is what the new code checks for, and that is also why ignoring
the check really shouldn't be a security issue.
Because if it turns out that somebody wrote to it, and the write
succeeded, then obviously the "set_disk_ro()" usage was simply wrong.
Now, I do agree that it 100% makes sense to have a layer like md/lvm
be able to virtually mark volumes read-only. If only exactly to
emulate the "this is like a write-protected floppy or a cd-rom"
behavior.
So the DM_READONLY_FLAG makes conceptual sense.
But at the same time, if the DM_READONLY_FLAG was _wrong_, then it
also makes a ton of sense to just say "oh, it was wrong, we'll ignore
it".
Exactly because it was never supposed to be about security, and it was
about other things.
See?
Linus
