Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221212123348.169903-1-brauner@kernel.org>
In-Reply-To: <20221212123348.169903-1-brauner@kernel.org>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 12 Dec 2022 19:28:59 -0800
Message-ID: <CAHk-=wj4BpEwUd=OkTv1F9uykvSrsBNZJVHMp+p_+e2kiV71_A@mail.gmail.com>
Subject: Re: [GIT PULL] vfsuid updates for v6.2
To:     Christian Brauner <brauner@kernel.org>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.

Yes, yes, I understand why they exist (those crazy IMA rules), but I
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.

                Linus