On Wed 14-06-23 10:18:16, Christian Brauner wrote: > On Wed, Jun 14, 2023 at 12:17:26AM -0700, Christoph Hellwig wrote: > > On Tue, Jun 13, 2023 at 08:09:14AM +0200, Dmitry Vyukov wrote: > > > I don't question there are use cases for the flag, but there are use > > > cases for the config as well. > > > > > > Some distros may want a guarantee that this does not happen as it > > > compromises lockdown and kernel integrity (on par with unsigned module > > > loading). > > > For fuzzing systems it also may be hard to ensure fine-grained > > > argument constraints, it's much easier and more reliable to prohibit > > > it on config level. > > > > I'm fine with a config option enforcing write blocking for any > > BLK_OPEN_EXCL open. Maybe the way to it is to: > > > > a) have an option to prevent any writes to exclusive openers, including > > a run-time version to enable it > > I really would wish we don't make this runtime configurable. Build time > and boot time yes but toggling it at runtime makes this already a lot > less interesting. I see your point from security POV. But if you are say a desktop (or even server) user you may need to say resize your LVM or add partition to your disk or install grub2 into boot sector of your partition. In all these cases you need write access to a block device that is exclusively claimed by someone else. Do you mandate reboot in permissive mode for all these cases? Realistically that means such users just won't bother with the feature and leave it disabled all the time. I'm OK with such outcome but I wanted to point out this "no protection change after boot" policy noticably restricts number of systems where this is applicable. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
