[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhS5ar0aU8Q6Ky133o=zYMHYRf=wxzTpxP+dtA=qunhcmw@mail.gmail.com>
Date: Mon, 16 Sep 2024 06:46:10 -0400
From: Paul Moore <paul@...l-moore.com>
To: Jann Horn <jannh@...gle.com>, David Howells <dhowells@...hat.com>
Cc: Jeffrey Altman <jaltman@...istor.com>, openafs-devel@...nafs.org,
James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>,
John Johansen <john.johansen@...onical.com>, Jarkko Sakkinen <jarkko@...nel.org>,
Mickaël Salaün <mic@...ikod.net>,
Günther Noack <gnoack@...gle.com>,
Stephen Smalley <stephen.smalley.work@...il.com>, Ondrej Mosnacek <omosnace@...hat.com>,
Casey Schaufler <casey@...aufler-ca.com>, linux-afs@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org,
apparmor@...ts.ubuntu.com, keyrings@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: Can KEYCTL_SESSION_TO_PARENT be dropped entirely? -- was Re:
[PATCH v2 1/2] KEYS: use synchronous task work for changing parent credentials
On Tue, Sep 10, 2024 at 4:49 PM Paul Moore <paul@...l-moore.com> wrote:
> On Thu, Aug 15, 2024 at 4:00 PM Jann Horn <jannh@...gle.com> wrote:
> > On Thu, Aug 15, 2024 at 9:46 PM David Howells <dhowells@...hat.com> wrote:
> > > Jann Horn <jannh@...gle.com> wrote:
> > >
> > > > Rewrite keyctl_session_to_parent() to run task work on the parent
> > > > synchronously, so that any errors that happen in the task work can be
> > > > plumbed back into the syscall return value in the child.
> > >
> > > The main thing I worry about is if there's a way to deadlock the child and the
> > > parent against each other. vfork() for example.
> >
> > Yes - I think it would work fine for scenarios like using
> > KEYCTL_SESSION_TO_PARENT from a helper binary against the shell that
> > launched the helper (which I think is the intended usecase?), but
> > there could theoretically be constellations where it would cause an
> > (interruptible) hang if the parent is stuck in
> > uninterruptible/killable sleep.
> >
> > I think vfork() is rather special in that it does a killable wait for
> > the child to exit or execute; and based on my understanding of the
> > intended usecase of KEYCTL_SESSION_TO_PARENT, I think normally
> > KEYCTL_SESSION_TO_PARENT would only be used by a child that has gone
> > through execve?
>
> Where did we land on all of this? Unless I missed a thread somewhere,
> it looks like the discussion trailed off without any resolution on if
> we are okay with a potentially (interruptible) deadlock?
As a potential tweak to this, what if we gave up on the idea of
returning the error code so we could avoid the signal deadlock issue?
I suppose there could be an issue if the parent was
expecting/depending on keyring change from the child, but honestly, if
the parent is relying on the kernel keyring and spawning a child
process without restring the KEYCTL_SESSION_TO_PARENT then the parent
really should be doing some sanity checks on the keyring after the
child returns anyway.
I'm conflicted on the best way to solve this problem, but I think we
need to fix this somehow as I believe the current behavior is broken
...
--
paul-moore.com
Powered by blists - more mailing lists