On Wed, Feb 19, 2020 at 03:48:37PM -0600, Serge E. Hallyn wrote: > On Wed, Feb 19, 2020 at 01:35:58PM -0600, Serge E. Hallyn wrote: > > On Tue, Feb 18, 2020 at 03:33:46PM +0100, Christian Brauner wrote: > > > With fsid mappings we can solve this by writing an id mapping of 0 > > > 100000 100000 and an fsid mapping of 0 300000 100000. On filesystem > > > access the kernel will now lookup the mapping for 300000 in the fsid > > > mapping tables of the user namespace. And since such a mapping exists, > > > the corresponding files will have correct ownership. > > > > So if I have > > > > /proc/self/uid_map: 0 100000 100000 > > /proc/self/fsid_map: 1000 1000 1 > > Oh, sorry. Your explanation in 20/25 i think set me straight, though I need > to think through a few more examples. > > ... > > > 3. If I create a new file, as nsuid 1000, what will be the inode owning kuid? > > (Note - I edited the quoted txt above to be more precise) > > I'm still not quite clear on this. I believe the fsid mapping will take > precedence so it'll be uid 1000 ? Per mount behavior would be nice there, > but perhaps unwieldy. The is_userns_visible() bits seems to be an attempt at understanding what people would want per-mount, with a policy hard coded in the kernel. But maybe per-mount behavior can be solved more elegantly with shifted bind mounts, so we can drop all that from this series, and ignore per-mount settings here? Tycho _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
