Hello, Alan. On Fri, Nov 02, 2012 at 08:48:25PM +0000, Alan Cox wrote: > If you look back through the archive you'll find people have been > spending a good decade bitching about the lack of filter configurability > and trying to get someone else to fix it. > > The BPF filter is simpler than just about any other implementation > because the tools exist and are used for lots of other things and it has > an API that is precisely defined as well as kernel calls to run the > filter.
Sure, if we *have* to go for flexible filtering, BPF would be the right way to do it. I'm just not convinced such flexibility is justified. > Some reasons for it > > - giving people access to parts of disks Are we gonna implement random range restriction inside a partition too? If we want to check against partition ranges for allowed SG_IO commands, by all means, but it can easily be implemented as part of the fixed filter. > - allowing access to specific vendor specific commands on certain > non-standard CD and DVD drives so they can be used for burning but you > can't trash them At this point, most burning commands are standardized, and optical drives are generally on the way out. If you absolutely have to use some vendor specific commands, be root. > - giving end users minimal access to things like SMART but only on drives > where it is safe End users already have pretty good access to SMART data via udisks and it's way more flexible and intelligent than some in-kernel filter. > - giving a user a SCSI disk or partition to play with but preventing them > issuing weird ass commands that can disrupt other devices in the fabric > (like drive to drive transfers, some kinds of resets, management > commands) > - minimising the ability of a VM to do damage if compromised while > maximising its raw access to a device Maybe, I don't know. It all sounds highly marginal to me. For complex/intelligent access policies, kernel isn't the right place to do it anyway - you want strong integration with the rest of the system especially for desktop. Ones which can justify kernel-side filtering would be things which are pretty low-level and require low overhead. I think VMs fall in this category, but then again being able to bypass standard filters seems workable enough for that. Sure, an extra layer of filtering on top could be nice but again I just don't think that's a strong enough justification. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
