On Sat, May 25, 2013 at 01:14:37PM +0200, Paolo Bonzini wrote: > > Don't think we can. It'd be a behavior change clearly visible to > > userland at this point. > > We can (and even for MMC) if it is a build-time configuration knob. It > would satisfy those people who want the CVE fixed, as long as userspace > gets some configurability. I don't think that's a good idea. We can gradually try to phase it out by triggering warning message if SG_IO commands are issued to !MMC devices but I'm not sure that'd be worth the effort. > > * Merge the patch to give out SG_IO access along with write access, so > > the use cases which want to give out SG_IO access can do so > > explicitly and be fully responsible for the device. This makes > > sense to me. If one wants to be allowed to issue raw commands to > > the hardware, one takes the full responsibility. > > That's not possible; it would make it impossible to do things like using > a privileged helper to open the file and passing it back via SCM_RIGHTS > to an unprivileged program (running as the user). This is the ptrace > attack that you mentioned. I have no idea what you're talking about. I'm describing the same thing you implemented and posted. -- tejun -- 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
