linux-kernel - How far should BLKROSET/set_device

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

Message-ID: <45C80C05.6090807@sandeen.net>
Date:	Mon, 05 Feb 2007 23:03:01 -0600
From:	Eric Sandeen <sandeen@...deen.net>
To:	linux-kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: How far should BLKROSET/set_device_ro() go?

While looking at another bug a while ago, I noticed that in 2.6 at 
least, set_device_ro() sets the policy on the hd_struct to mark it 
readonly, but it appears that IO is only really blocked from userspace, 
via generic_write_checks().

There are bdev_read_only() checks in other places, but nothing in a 
common spot to reject all possible IO.

Should we have something in generic_make_request() to reject ALL IO on a 
readonly bdev, or is that further than the policy is supposed to go?  Or 
is it up to each location that might possibly issue that IO to check it 
and be well-behaved?

The motivation for this investigation was ext3 happily doing orphan 
inode recovery on read-only lvm snapshot....

Thanks,

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