On Sat, Aug 31, 2013 at 9:45 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > 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. Fair enough. I didn't realize that you had to own the pid namespace. --Andy -- 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
