Il 12/06/2012 18:55, Alan Cox ha scritto: > On Tue, 12 Jun 2012 18:08:32 +0200 > Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > >> Persistent reservations commands cannot be issued right now without >> giving CAP_SYS_RAWIO to the process who wishes to send them. This >> is a bit heavy-handed, allow these two commands. >> >> Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx> >> --- >> Ok for 3.5 as well? > > NAK. > > 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. > 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. > 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. Paolo -- 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
