W dniu 21 marca 2011 19:37 użytkownik John Calixto <john.calixto@xxxxxxxxxxxxxx> napisał: > On Sat, 19 Mar 2011, Michał Mirosław wrote: >> W dniu 18 marca 2011 20:26 użytkownik Arnd Bergmann <arnd@xxxxxxxx> napisał: >> > On Friday 18 March 2011 18:56:53 Michał Mirosław wrote: >> >> If that's going to be used by possibly unprivileged userspace process, >> >> then this passthrough should filter and validate all commands it >> >> passes to hardware. If there is a possibility of some command sequence >> >> to generate undefined or otherwise unwanted results, then you need >> >> state tracker that will disallow that sequence to be generated by >> >> unprivileged process. >> > We have precedence for direct host commands in a few other >> > block drivers. In general, any user who can open the block >> > device can issue all commands unless they can directly destroy >> > the hardware. On normal systems, the only user that has write >> > access to block devices is root. >> In this case, a process having access to one partition can disrupt >> other partitions on the same card even if it has no access to them in >> any other way. > This is true, but I can already wreak havoc on partitions for any block > device by opening up the block device node directly, seeking and > writing. If I have write access to the block device, I can do whatever > I want. You're talking about reverse case to what I described. Using a partition, you shouldn't be able to effect the device in a way that extends part this particular partition. >> It is not that unusual on "normal systems" to give write access to >> some partition or device to unprivileged users. Database volumes are >> one example. > Are you talking about the device nodes themselves, or about access to > the mounted filesystems that live on those devices/partitions? It seems > like if you give unprivileged users write access to the raw block > device, you should expect a lot more trouble from > runaway/malicious/accidental writes than you would from > application-specific commands being sent via ioctl. I don't exactly see what's your point here. If you say that writes are less dangerous than ioctls, then I agree. Even now, for some block ioctls you need CAP_SYS_ADMIN because of that. Best Regards, Michał Mirosław -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
