> > - 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.
Really. Can your filter implement it only for certain commands, and only for certain vendor specific commands ? Not really because your filter is fixed - it has policy in kernel which is the wrong place for device specific stuff. And if you add it to the "fixed" policy how much code and ioctls is that to specify ranges by command and pass partitions when they are device mapper user space created mappings ? More code than the BPF interface and more new APIs. > > - 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. So that translates to me as "There is a good reason, but if your drive is one of the awkward ones then f**k you go use root". Again policy in the kernel just creates inflexibility and is the wrong place for it. > > - 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. Thats a bit Gnome developer - "Our way or the highway". The point of having a filter is that you put policy in user space. If you don't care the default filter carries on just working, if you do care you can change stuff with BPF. > > - 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. If you are doing virtual machines it is far from marginal. > For complex/intelligent access policies, kernel isn't the right place > to do it anyway So why are you arguing for kernel policies which is exactly what the fixed ones are ? The BPF ones moves the policy to user space ! Alan -- 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/