All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mateusz Guzik <mjguzik@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Moore <paul@paul-moore.com>,
	viro@zeniv.linux.org.uk, serge@hallyn.com,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH v2 2/2] vfs: avoid duplicating creds in faccessat if possible
Date: Tue, 24 Jan 2023 19:42:55 +0100	[thread overview]
Message-ID: <CAGudoHG22iS3Bt1rh_kEJDEstj3r1Mj4Z305vqRbP8vBjQZ3dg@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wiG5wdWrx2uXRK3-i31Zp416krnu_KjmBbS3BVkiAUXLQ@mail.gmail.com>

On 1/24/23, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, Jan 24, 2023 at 9:00 AM Paul Moore <paul@paul-moore.com> wrote:
>>
>> My main concern is the duplication between the cred check and the cred
>> override functions leading to a bug at some unknown point in the
>> future.
>
> Yeah, it might be good to try to have some common logic for this,
> although it's kind of messy.
>
> The access_override_creds() logic is fairly different from the "do I
> need to create new creds" decision, since instead of *testing* whether
> the fs[ug]id and [ug]id matches, it just sets the fs[ug]id to the
> expected values.
>
> So that part of the test doesn't really exist.
>
> And the same is true of the !SECURE_NO_SETUID_FIXUP logic case - the
> current access() override doesn't _test_ those variables for equality,
> it just sets them.
>
> So Mateusz' patch doesn't really duplicate any actual logic, it just
> has similarities in that it checks "would that new cred that
> access_override_creds() would create be the same as the old one".
>
> So sharing code is hard, because the code is fundamentally not the same.
>
> The new access_need_override_creds() function is right next to the
> pre-existing access_override_creds() one, so at least they are close
> to each other. That may be the best that can be done.
>
> Maybe some of the "is it the root uid" logic could be shared, though.
> Both cases do have this part in common:
>
>         if (!issecure(SECURE_NO_SETUID_FIXUP)) {
>                 /* Clear the capabilities if we switch to a non-root user
> */
>                 kuid_t root_uid = make_kuid(override_cred->user_ns, 0);
>                 if (!uid_eq(override_cred->uid, root_uid))
>
> and that is arguably the nastiest part of it all.
>
> I don't think it's all that likely to change in the future, though
> (except for possible changes due to user_ns re-orgs, but then changing
> both would be very natural).
>

You could dedup make_kuid + uid_eq check, but does it really buy
anything?

ns changes which break compilation will find both spots. Similarly
any grep used to find one should also automagically find the other
one.

I think this patch generated way more discussion than it warrants,
especially since I deliberately went for the trivial approach in
hopes of avoiding this kind of stuff.

So how about I simply respin with the comment I mailed earlier,
repasted here for reference (with a slight tweak):

diff --git a/fs/open.c b/fs/open.c
index 3c068a38044c..756177b94b04 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -407,6 +407,11 @@ static const struct cred *access_override_creds(void)
        if (!override_cred)
                return NULL;

+       /*
+        * XXX access_need_override_creds performs checks in hopes of
+        * skipping this work. Make sure it stays in sync if making any
+        * changes in this routine.
+        */
        override_cred->fsuid = override_cred->uid;
        override_cred->fsgid = override_cred->gid;

sounds like a plan?

-- 
Mateusz Guzik <mjguzik gmail.com>

  reply	other threads:[~2023-01-24 18:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-16 21:21 [PATCH v2 1/2] capability: add cap_isidentical Mateusz Guzik
2023-01-16 21:21 ` [PATCH v2 2/2] vfs: avoid duplicating creds in faccessat if possible Mateusz Guzik
2023-01-20 20:45   ` Paul Moore
2023-01-21  0:50     ` Mateusz Guzik
2023-01-21  1:18       ` Mateusz Guzik
2023-01-23 21:29       ` Paul Moore
2023-01-24 10:16         ` Mateusz Guzik
2023-01-24 17:00           ` Paul Moore
2023-01-24 17:14             ` Linus Torvalds
2023-01-24 18:42               ` Mateusz Guzik [this message]
2023-01-24 20:37                 ` Linus Torvalds
2023-01-24 21:33               ` Paul Moore
2023-01-25 15:00                 ` Mateusz Guzik
2023-01-25 16:17                   ` Mateusz Guzik
2023-01-25 17:11                     ` Paul Moore
2023-01-25 17:07                   ` Paul Moore

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=CAGudoHG22iS3Bt1rh_kEJDEstj3r1Mj4Z305vqRbP8vBjQZ3dg@mail.gmail.com \
    --to=mjguzik@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.