On Tue, 2012-06-12 at 18:54 +0200, Paolo Bonzini wrote: > Il 12/06/2012 18:24, Paolo Bonzini ha scritto: > > Il 12/06/2012 18:21, James Bottomley ha scritto: > >>>> 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. > >> > >> Why is this heavy handed? If you remove CAP_SYS_RAWIO, any userspace > >> process can send these, which would allow any user to completely disrupt > >> a SAN by injecting spurious reservations ... that doesn't look to be > >> terribly safe for an operating system running in a data centre. > > > > It is heavy-handed because: > > > > 1) there are still other protections such as DAC (both Unix permissions > > and ACLs) and SELinux; CAP_SYS_RAWIO is effectively the same as root. > > > > 2) if any user could disrupt the SAN by injecting spurious reservations > > just by having his laptop's root password, that data centre wouldn't be > > terribly safe to begin with. > > 3) assume that with this patch user X could disrupt the SAN by injecting > spurious reservations, e.g. forbidding another user from writing some > data. Then they could also destroy those same data even without this > patch, which is just as disrupting. > > This is because you still need write permission to the device to issue > reservations. Read permission will only let you use PERSISTENT RESREVE IN. I don't think you understand how persistent reservations work. The first thing I'll say is I agree with Alan. Unless you can justify why you want to relax permissions I'm not going to do it. But secondly, the reason we're so up in arms about SCSI-3 PR is that there's a feature called reservation by transport ID. This is used to reserve multipath devices when one of the paths is down. Effectively it allows a PR-OUT command to set a reservation on any LUN with access only to one of them. It's definitely a hack in the SCSI standard, but it's not one that can be controlled by a unix like permission model. Write access to *any* LUN allows you to reserve *all* luns. James -- 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
