Mike Snitzer <snitzer@xxxxxxxxxx> writes: > What layer establishes access rights to historically root-only > priviledged block devices? Is it user namespaces? Block devices are weird. Mounts historically have not checked the permissions on the block devices because a mounter has CAP_SYS_ADMIN. Unprivileged users are allowes to read/write block devices if someone has given them permissions on the device node in the filesystem. The thinking with this patchset is to start performing the normal block device access permission checks when mounting filesystems when the mounter does not have the global CAP_SYS_ADMIN permission. The truth is we are not much past the point of realizing that there were no permission checks to use the actual block device passed in to mount, so we could still be missing something. There is a lot going on with dm, md, and lvm. I don't know if the model of just look at the block device inode and perform the permission checks is good enough. > I haven't kept up with user namespaces as it relates to stacking block > drivers like DM. But I'm happy to come up to speed and at the same time > help you verify all works as expected with DM blocks devices... We are just getting there. But if you can help that would be great. The primary concern with dm is what happens when unprivileged users get ahold of the code, and what happens when evil users corrupt the on-disk format. In principle dm like loop should be safe to use if there are not bugs that make it unsafe for unprivileged users to access the code. The goal if possible is to run things like docker without needed to be root or even more fun to run docker in a container, and in general enable nested containers. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
