On Tue, Jun 01, 2010 at 09:09:10AM +1000, James Morris wrote: > On Mon, 31 May 2010, Kees Cook wrote: > > > Expecting the push-back from VFS, I wrote this patch against commoncaps. > > > > James, would you take it there (along with the patch to SELinux to call > > out to commoncaps) if there is no way to proceed with the VFS core towards > > solving this? > > Isn't this just bypassing the VFS objections? Well, that's what I'm trying to understand. It sounds like there is some general agreement that the issue needs to be solved, but some folks do not want it in the core VFS. As in, the objections aren't with how symlink behavior is changed, just that the changes would be in the fs/ directory. My rationale is that if it's in commoncaps, it's effective for everyone, so it might as well be in core VFS. If the VFS objections really do boil down to "not in fs/" then I'm curious if doing this in commoncaps is acceptable. Ironically, doing this in commoncaps is the patch I sent. :P To me, the VFS objections really seem like a obfuscated version of "this should not be in the kernel in any way", which I think does not admit to the problem existing in the first place. Either there is a problem or there isn't. If there is a problem, it should be fixed. I think there is a problem with the kernel semantics of symlinks. Therefore, it should be fixed in the kernel. I personally do not care if it's in fs/ or security/, I'm just seeking the most efficient and complete solution. -Kees -- Kees Cook Ubuntu Security Team -- 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
