Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: > On Wed, Jun 3, 2015 at 2:15 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: >> >> Not allowing programs to clear nosuid, nodev, and noexec on new mounts >> of sysfs or proc will cause lxc and libvirt-lxc to fail to start (a >> regression). There are no device nodes or executables on sysfs or >> proc today which means clearing these flags is harmless today. >> >> Instead of failing the fresh mounts of sysfs and proc emit a warning >> when these flags are improprely cleared. We only reach this point >> because lxc and libvirt-lxc clear flags they mount flags had not >> intended to. >> >> In a couple of kernel releases when lxc and libvirt-lxc have been >> fixed we can start failing fresh mounts proc and sysfs that clear >> nosuid, nodev and noexec. Userspace clearly means to enforce those >> attributes and historically they have avoided bugs. > > At the very least, I think this should be folded in so that the ABI > doesn't break in the middle of the series. Nothing in any of these patches has ever broken the ABI. The bits have always been interpreted with the same meaning. I have been going back and forth on exactly the best way to handle this because I don't like breaking working executables even for valid reasons. I think I have finally reach my personal peace on this issue. Not requiring the presence of nosuid and noexec on a fresh mount of proc and sysfs if the original mount has nosuid or noexec is a security issue as what proc and sysfs implement in the future can not be known. The one possible way to remedy this is to implicity add nosuid and noexec as appropriate unfortunately that would break the ABI as it changes the interpretation of the bits in the userspace interface, and the day proc or sysfs changes and we honest to truly want to enable suid exectuables on proc or sysfs we would not be able to. :( So implicitly adding attributes is out. As the current implementation of proc and sysfs are known I agree it does not make sense to backport the enforcement of nosuid and noexec. So I have split the patch. See my for-testing branch and shortly my for-next branch. It only takes two or three line patches in the affected userspace executables, and a 5 minute test. So a warning printk does not actually make sense. If the authors of lxc and libvirt-lxc have not taken the time to fix their code by the time this code lands in a stable release (in 2 months or so) no amount of other warnings are going to be enough. 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
