ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: > >> On Tue, Aug 27, 2013 at 2:44 PM, Eric W. Biederman >> <ebiederm@xxxxxxxxxxxx> wrote: >>> >>> Rely on the fact that another flavor of the filesystem is already >>> mounted and do not rely on state in the user namespace. >> >> Possibly dumb question: does this check whether the pre-existing mount >> has hidepid set? > > Not currently. > > It may be worth doing something with respect to hidepid. I forget what > hidepid tries to do, and I need to dash. But feel free to cook up a > follow on patch. So I have thought about this a bit more. hidepid hides the processes that ptrace_may_access will fail on. You can only reach the point where an unprivileged mount of a pid namespace is possible if you have created both a user namespace and a pid namespace. Which means the creator of the pid namespace will be capable of ptracing all of the other processes in the pid namespace (ignoring setns). So I don't see a point of worry about hidepid or the hidepid gid on child pid namespaces. The cases it is attempting to protecting against really don't exist. 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
