Re: [GIT PULL] vfsuid updates for v6.2

From: Christian Brauner <brauner@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] vfsuid updates for v6.2
Date: Tue, 13 Dec 2022 10:19:37 +0100	[thread overview]
Message-ID: <20221213091937.dmshin7hd6hqsliq@wittgenstein> (raw)
In-Reply-To: <CAHk-=wj4BpEwUd=OkTv1F9uykvSrsBNZJVHMp+p_+e2kiV71_A@mail.gmail.com>

On Mon, Dec 12, 2022 at 07:28:59PM -0800, Linus Torvalds wrote:
> On Mon, Dec 12, 2022 at 4:34 AM Christian Brauner <brauner@kernel.org> wrote:
> >
> > This pull request converts all remaining places that still make use of non-type
> > safe idmapping helpers to rely on the new type safe vfs{g,u}id based helpers.
> > Afterwards it removes all the old non-type safe helpers.
> 
> So I've pulled this, but I'm not entirely happy about some of those
> crazy helpers.
> 
> In particular, the whole "ordering" helpers are really not something
> that should be used in general, I feel. I'm talking about
> vfsuid_gt_kuid() and friends - it's an entirely insane operation and
> makes no sense at all.

Oh yes, I very much agree.

> 
> Yes, yes, I understand why they exist (those crazy IMA rules), but I

I would've really liked to have avoided their existence altogether but I
have no clear idea what ima is doing with these comparisons. And
everytime we do wider scoped vfs work I spend about 1 or 2 good weeks in
security/ just to understand what all the various security modules do,
audit callchains and then come up with something that doesn't break half
of them. And often this means unpleasant compromises in the vfs layer
which I really don't like.

And just to be clear, I don't want to be on of those "LSMs are bad"
people. I do really think they provide additional value.
But I think it's fair to acknowledge that the hook infrastructure with
multiple LSMs makes the vfs and developers pay when reworking codepaths.

And the fact that some things that are LSM-like (ima etc.) have separate
hooks doesn't help either.

> feel that those functions *really* shouldn't be exposed to anybody
> else.
> 
> IOW, making those insane functions available in <linux/idmapping.h>
> really seems wrong to me. They are crazy special cases, and I think
> they should exist purely in that crazy ima_security file.
> 
> Again - I've pulled this, but I'm hoping to see a future commit that
> limits that craziness to the only user, in the hope that this disease
> will never spread.

Let me see what I can do about this. Hopefully I can still find
something during the merge window.