Christian Brauner <christian.brauner@xxxxxxxxxx> writes: > On Mon, May 04, 2020 at 11:25:07AM -0500, Eric W. Biederman wrote: >> >> I am not thrilled about treating nstype as a flags fields when it is not >> currently. It was my hope when I designed the interface that not >> treating nstype as a flags field would save us from the problem of bits >> running out. > > Hm, I researched the setns() syscall history before that and I didn't > see that reasoning anywhere. The "nstype" arg was originally advertised > on the list as "having a flags field is useful in general". Take a look at the code. At the end of the day nstype is not treated at all like a flags field. It isn't a very important point. And it was certainly easier to use the existing bits for essentially their existing meanings. But it was certainly something I was thinking at the time. I think I left it as we can see either way, depending on how things evolve. I can imagine a use for a nstype being a single namespace from a pidfd. Do you have any actual usecases for setting some but not all of the namespaces from a pidfd? If we don't have a compelling reason I would like to kick that can down the road a ways farther. I am also remembering that that setns freed the low 8 bits. Which gave some freedom beyond clone. >> That aside. It would be very good if the default version of setting >> everything from a pidfd would set the root directory from the process it >> is copying everything else from. > > I'm not sure I follow completely. If you specify CLONE_NEWNS then we do > set the root directory with set_fs_root() in commit_nsset(). Or are you > saying we should always do that independent of whether or not > CLONE_NEWNS is specified? And if so could you explain why we'd want > that? I'm sure I'm missing something! I am suggesting that when we do: "setns(pidfd, 0)" or "setns(pidfd, SETNS_PIDFD)" That the result is not just the namespaces changing but also the root directory changing to the pids root directory. Something where the whole is greater than the parts. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
