On Wed, 2021-12-01 at 17:09 -0500, Stefan Berger wrote: > On 12/1/21 17:01, James Bottomley wrote: [...] > > OK, I think I figured it out. When I applied your patches, it was > > on top of my existing ones, so I had to massage them a bit. > > > > Your problem is the securityfs inode creation is triggered inside > > create_user_ns, which means it happens *before* ushare writes to > > the proc/self/uid_map file, so the securityfs_inodes are always > > created on an empty mapping and i_write_uid always sets the inode > > uid to -1. > > Right, the initialization of the filesystem is quite early. > > > > I don't see this because my setup for everything is triggered off > > the first use of the IMA namespace. You'd need to have some type > > of lazy setup of the inodes as well to give unshare time to install > > the uid/gidmappings. > > What could trigger that? A callback while mounting - but I am not > sure where to hook into then. What is your mechanisms to trigger as > the 'first use of the IMA namespace'? What is 'use' here? use for me is first event that gets logged in the new namespace. However, I don't think this is a good trigger, it's just a random thing I was playing with. Perhaps trigger on mount is a good one ... that could be done from securityfs_ns_init_fs_context? James
