> > Also I tend to side with Alan that I don't quite see > > the point in trying to restrict CAP_SYS_RAWIO threads and thus breaking the > > compatibility > > For example, we have a customer that wants this: > > * a VM should be able to send vendor-specific commands to a disk via > SG_IO (vendor-specific commands require CAP_SYS_RAWIO). > > * they want to assign logical volumes or partitions to the same VM > without letting it read or write outside the logical volume or partition. And if the process has CAP_SYS_RAWIO it can do it anyway. So not only is your agenda destructive - it doesn't actually work. > Of course a better solution for this would be customizable filters for > SG_IO commands, where a privileged application would open the block > device with CAP_SYS_RAWIO, set the filter and hand the file descriptor > to QEMU. Or alternatively some extension of the device cgroup. But > either solution would require a large amount of work. Or you could just do the special case ioctl magic out of band in the apps. It's hardly an ultra performance critical path for the SG_IO cases. Customisable filters are not hard. We've got all the filtering code in kernel and the ability to verify filters, even the ability to JIT them. Just support adding/removing/running a BPF filter on the channel in question. So it shouldn't be much code to do what you want. 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
