On Tue, Oct 8, 2013 at 10:50 PM, Eric W. Biederman <ebied...@xmission.com> wrote:
> If we are going to fix the VFS deficiency we have to let these changes > happen in other mount namespaces. To make that safe it has to be > sufficient to rely on the directory permissions and the conditions that > ensure that the directory permissions are sufficient. Yes. > So I find it far safer to allow as much as possible even in the local > mount namespace so we can actually see if there are problems with > relying on the directory permissions. But it's not safer in terms of breaking legacy environments, which are single namespace, usually. I see it this way: the current behavior (blocking unlink/rename if mounted) may not be nice, but it's expected. But once we have multiple namespaces it becomes problematic. Just like network filesystems where we cannot prevent unlink on another host just because it's mounted on this. So we have to have some way of dealing with this. Is it worth changing behavor in the "current namespace" case too? It has advantages, but it's not absolutely necessary and there are unknown dangers. But if we disable it for rmdir() then what's the point in enabling it for unlink()? Directory mounts far outnumber non-directory ones, so the additional testing is minimal, but the holes left are probably just as real. And there's rename(). We have a real security hole in fusermount by allowing it in the local namespace. I don't think changing the behavior of rename() in the local namespace is important enough to risk such problems. And as Andy pointed out, we can just have an option to turn it on and that's that. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
