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. > > 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.
