On Tue, 22 Mar 2011, Michał Mirosław wrote: > >> 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. > Ah - I see. Sorry, I misread your comment. > >> 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. > In general, I agree with your caution. My point is that I'm not sure this type of protection belongs in the kernel. We use permissions and "medium-privileged" role users all the time to marshal access to sensitive files and devices. This is a problem that has been solved in userspace. You don't let normal user "john" have the same access to device nodes or even files and directories that you would for role user "database", or role user "webserver". (Actually, you probably shouldn't let normal user "john" have access to anything - I hear he's trouble!) John
