W dniu 22 marca 2011 23:31 użytkownik John Calixto <john.calixto@xxxxxxxxxxxxxx> napisał: > On Tue, 22 Mar 2011, Michał Mirosław wrote: >> >> 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!) When you grant write access to a device to some user, you should expect that it is all you are granting. There shouldn't be any hidden doors that, for example, if underlying device is SD card then you can destroy it by this ioctl(). Not counting wearing or WORM-like media, writes (also erasing, changing encryption keys, etc.) are undoable. Other forms of access should be granted separately (by capabilities or other means). 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
