Hey, Paolo. On Sat, Nov 03, 2012 at 02:20:14PM +0100, Paolo Bonzini wrote: > As to implementing the ioctl, it's all but trivial. For one thing, you > have to make the block device ioctl op take a "struct file". I have > been asking Al Viro about it for 6 months and I haven't got any answer yet.
I don't think that really matters. If necessary, just change it. > Second, getting a security-sensitive ioctl right is hard, as you > demonstrated yourself in this thread by proposing a gapingly insecure > approach. Adding a little bit of customization to the current solution > may be but a local optimum, but you cannot really get it wrong. Eh? Sure, I was in "who cares about SG_IO?" area a bit but that has nothing to do with the interface being an ioctl. It's a binary switch ioctl, it's not too difficult to get right. > Because _this_ is the simplest possible. I guess we'll have to agree to disagree. This is way more complex. You need to review what's going on with the userland tools and inspect weird sysfs files to actually know what the system policy is. > I proposed a way to implement the ultimately flexible solution (BPF) and > you shot it down because it was too complex. Alan is showing you with > multiple examples of why the flexibility would be useful (perhaps nobody > would use it, but the use cases _are_ there), and you are mostly > ignoring them. The only valid use case was using proprietary commands during CD burning. At this point, that's a really really minor use case IMHO. I think adding full BPF filtering on SG_IO for that is rather silly. 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/
