Message-ID: <29770c86261bbc7f6380c7c355ecb6a1c9f40980.camel@linux.ibm.com>
Subject: Re: [RFC 20/20] ima: Setup securityfs_ns for IMA namespace
From:   James Bottomley <jejb@linux.ibm.com>
Reply-To: jejb@linux.ibm.com
To:     Stefan Berger <stefanb@linux.ibm.com>,
        linux-integrity@vger.kernel.org
Cc:     zohar@linux.ibm.com, serge@hallyn.com,
        christian.brauner@ubuntu.com, containers@lists.linux.dev,
        dmitry.kasatkin@gmail.com, ebiederm@xmission.com,
        krzysztof.struczynski@huawei.com, roberto.sassu@huawei.com,
        mpeters@redhat.com, lhinds@redhat.com, lsturman@redhat.com,
        puiterwi@redhat.com, jamjoom@us.ibm.com,
        linux-kernel@vger.kernel.org, paul@paul-moore.com, rgb@redhat.com,
        linux-security-module@vger.kernel.org, jmorris@namei.org
Date:   Wed, 01 Dec 2021 17:19:03 -0500
In-Reply-To: <b8c21064-05f3-91a9-d23c-0417f046f4cc@linux.ibm.com>
References: <20211130160654.1418231-1-stefanb@linux.ibm.com>
         <20211130160654.1418231-21-stefanb@linux.ibm.com>
         <6599ac61289e3316bff53602a0bc5970133251aa.camel@linux.ibm.com>
         <f2113d60-49d3-2e2d-7dbe-b831035f96a1@linux.ibm.com>
         <f5e3101e8dee2aa0064e7b68992afe0143e22058.camel@linux.ibm.com>
         <9631d4b3-15f6-46f1-6441-98c1192be6b4@linux.ibm.com>
         <c6d7b9363991b80b2f55bbdb7e44c18ea45489da.camel@linux.ibm.com>
         <8d7b6d47-9001-1f47-bce8-e7fae28fafcf@linux.ibm.com>
         <38458eee904713824b85a2dcef248e752634f67c.camel@linux.ibm.com>
         <b8c21064-05f3-91a9-d23c-0417f046f4cc@linux.ibm.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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