Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx> writes: > > > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > >> From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> > >> > >> To keep things sane in the context of file descriptor passing derive the > >> user namespace that uids are mapped into from the opener of the file > >> instead of from current. > >> > >> When writing to the maps file the lower user namespace must always > >> be the parent user namespace, or setting the mapping simply does > >> not make sense. Enforce that the opener of the file was in > >> the parent user namespace or the user namespace whose mapping > >> is being set. > > > > Is there a reasonable use case for writing from the ns whose mapping > > is being set? Are you expecting cases where the child opens the file > > and passes it back to the parent to set the mappings? > > Passing the open mappings file no. Although by using seq_user_ns I do > make certain the semantics are correct if the file descriptor is passed, > but I did that on general principles. > > I expect a process in the user namespace to be able to meaningfully set > the mapping to some the current uid and the current gid. Sorry, I think a word is missing there. To be precise (bc I haven't thought about this much before as it's not my target goal :) you're saying if I'm uid 1000 gid 1000, I can create a new user namespace and, from inside that new userns (where I'm first uid/gid -1) I can map any uid+gid in the container to 1000 in the parent ns? Or is there something more? It still seems to me no less flexible to require being in the parent ns, so > >> + if ((seq_ns != ns) && (seq_ns != ns->parent)) > >> + return -EPERM; would become > >> + if (seq_ns != ns->parent) > >> + return -EPERM; I also wonder if -EINVAL would be a more appropriate choice here. We're trying to keep things sane, rather than saying "not allowed" for its own sake. -serge -- 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
