Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: > On 08/05/2014 05:57 PM, Eric W. Biederman wrote: > > Sorry for catching this late. I think this fix is likely to > unnecessarily break valid userspace due to an odd interaction. The code is correct and safe (no security issues), but yes a blind remount might hit a snag. If you can find a userspace application that matters I might care that a security fix breaks it. I think you have made a point that several more filesystems might be ok to not set nodev on (because we can not do anything to create device nodes on those filesystems). I personally would prefer the much more paranoid approach of only allowing device nodes on a unprivileged mount if we have audited all of the code paths and know it is safe for device nodes to appear there. I don't actually think anyone cares ad remounts of filesystems like tmpfs, mqueue, sysfs, proc, ramfs are all quite rare. Blind remounts are even rare. The normal userspace utilities look at the appropriate version of /proc/mounts on remount. These are not filesystems that a blind remount will likely be applied to. Furthermore there is work underway to prepare patches to allow "mount --bind -ro" to work as expected. That will further reduce the pressure from blind remounts. If there is an actual regression of actual code I am happy to deal with it. But having the MNT_NODEV on those mounts has been the case for a long time now and is not new (no regression). This change just closed the security hole that allowed nodev to be removed. And that security hole we need to have fixed. 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
