Miklos Szeredi <miklos@xxxxxxxxxx> writes: > On Fri, 06 Nov 2009, ebiederm@xxxxxxxxxxxx (Eric W. Biederman wrote: >> So far no one who believes this to be a security hole has found it >> worth their while to look at nd->intent.open in proc_pid_follow_link >> and write a patch. > > A rather disgusting patch that would be. The fact is, checking > permissions on follow_link makes little to no sense. Consider > truncate(2), for example. Will we add another intent for that? I > really hope not No. I was just thinking we have the open intent that is there for combining lookup and open. We can look test for LOOKUP_OPEN and do exactly what we need. > I'm more and more convinced, that the current behavior is the right > one. I think the 15 or so years we have had the current behavior without problems is persuasive. I think it is an interesting puzzle on how to get dup instead of reopen as there are cases where that could be useful behavior as well. The usefulness of an O_NONE flag increases significantly if you can open the reference file later with more permissions. Essentially making a hardlink into a running program. Hmm. Weird cases do seem to show up when the last dir entry is removed. I wonder if we want a rule that you can't open a file with link count of 0. Reasoning may get truly strange otherwise. 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
