All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] vfsuid updates for v6.2
Date: Mon, 12 Dec 2022 19:28:59 -0800	[thread overview]
Message-ID: <CAHk-=wj4BpEwUd=OkTv1F9uykvSrsBNZJVHMp+p_+e2kiV71_A@mail.gmail.com> (raw)
In-Reply-To: <20221212123348.169903-1-brauner@kernel.org>

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

  reply	other threads:[~2022-12-13  3:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-12 12:33 [GIT PULL] vfsuid updates for v6.2 Christian Brauner
2022-12-13  3:28 ` Linus Torvalds [this message]
2022-12-13  9:19   ` Christian Brauner
2022-12-15  7:37   ` Rasmus Villemoes
2022-12-13  3:49 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wj4BpEwUd=OkTv1F9uykvSrsBNZJVHMp+p_+e2kiV71_A@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.