> > Persistent reservations are exactly the kind of command that should have > > a security model attached to them. > > There is. It's called "chmod"; you don't give write access to LUNs to > random users. and SCM_RIGHTS is what lets you override it securely. Only you do - for virtual machines for example. > > Red Hat seems to be an ever growing source of "mummy its hard, lets > > disable all the security" type fixes. Please stop it. > > Last time you were complaining that I was turning things *off* (SG_IO to > partitions for root). Now you complain that I'm turning things *on*. > It's difficult to say they are the same thing. Though perhaps you were > talking about someone else. Last time you were trying to break stuff that worked and stop the privileged user doing it. This time you are tring to take away security features that users might be relying on. > > There is a sensible debate to be had about whether a lesser privilege > > ought to be allowed. The real fix to this as with half of the other > > crazy attempts to break all the security models that seem to keep spewing > > forth is for someone who cares about it (that seems to me Red Hat) add > > support for pushing a BPF filter onto a block device command queue. > > Sure; however, doing so requires access to some member of "struct file" > from SG_IO. Thus, ioctl would need to take a "struct file" rather than > just an fmode_t. > > The switch to fmode_t was done in 2007 by Al Viro. I would like to > understand the reasons for the switch; it seems to me that it was part > of the big kernel lock removal. If it's acceptable to undo it, I would > very much would like to add generic BPF filtering to SG_IO That would solve all sorts of problems in this area, so lets ping the man himself - Al ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
