On Wed, 2021-12-01 at 17:09 -0500, Stefan Berger wrote:
On 12/1/21 17:01, James Bottomley wrote:
[...]
quoted
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.
quoted
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