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

[Rasmus Villemoes <rasmus.villemoes@prevas.dk>]

On 13/12/2022 04.28, 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.
> 
> 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.

Yeah. Aside from assigning any semantics to < or > of [ug]ids, which is
something IMA apparently wants to do, taking the address of a static
inline in the first place is a code smell; that obviously forces the
compiler to emit a copy in the current TU. But the code compares stored
pointers to addresses of those static inlines, which would be completely
broken if this didn't happen to all be contained in a single TU. That's
quite subtle, and probably fowner_op would be better as an enum.

Rasmus