>> | > The logic seems simple: With newinstance create a private namespace. >> | > Without newinstance, bind to initial ns. >> | >> | But if I'm in a container in a new mounts ns and somehow managed >> | to umount -l /dev/pts, shouldn't i be able to remount my container's >> | devpts by just doing 'mount -t devpts devpts /dev/pts'? yes. That's the track we are following with the mq namespace. >> Now wouldn't that require us to associate the devpts mount with some >> notion of a container ? (a namespace object in nsproxy of container-init >> like we do with /proc). > > Yes. and it gets a little bit ugly because you need to maintain an internal mount associated with the namespace to be able to remount the same superblock when a : $ umount /dev/pts $ mount -t devpts devpts /dev/pts'? is done. So if you're using the mount option 'newinstance' to unshare the namespace, you end up doing the internal mount and the user mount under the same call, which is a bit weird, indeed. C. >> Yes, after 'umount -l' we have lost _that_ devpts ns and we may have to >> 'redo' the relevant container-init parts > > It all just feels fragile. > > I realize this is an attempt to do the 'pure fs approach' you were asked > to do. I just don't like the resulting _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers