Karel Zak: > [..] > >> My personal recommendation is not to use chroot with persistent mount >> namespaces. That just seems to keep unnecessary mounts around. Those >> extra mounts will almost certainly be a problem later when you discover >> you want to unmount one of those mounted filesystems you don't care >> about but are chrooting over. >> >> I think it would be quite reasonable to have an additional option to >> open things in the new mount namespace, just before exec. I just don't >> see how useful it would be. > > It would be solution for this use-case, but it will increase > complexity and I'm not sure this use-case is important enough. > > Especially if the all you need is to use chroot command before nsenter. > I don't think nsenter has to be all-in-one command. It's very basic > tool. > My nsenter code may be run inside or outside a chroot, I have no control over that in the general case - users decide whether they want to run it inside a chroot or not. The issue with using the chroot(1) command, is that you must give it the path to the chroot *from outside the chroot*. I don't know of a clean way to figure this out from my code, that starts life running from inside the chroot, and just wants to unshare part of the tree that it sees there. An option to open root/wd in the new ns, sounds like it would allow me (and others) to write code that is chroot-independent. I'd very much appreciate that. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
