[PATCH v5 1/2] rust: task: clarify comments on task UID accessors

Alice Ryhl aliceryhl at google.com
Tue Jul 7 21:40:37 UTC 2026


On Tue, Jul 7, 2026 at 9:10 PM Paul Moore <paul at paul-moore.com> wrote:
>
> On Jul  3, 2026 Alice Ryhl <aliceryhl at google.com> wrote:
> >
> > Linux has separate subjective and objective task credentials, see the
> > comment above `struct cred`. Clarify which accessor functions operate on
> > which set of credentials.
> >
> > Also document that Task::euid() is a very weird operation. You can see how
> > weird it is by grepping for task_euid() in the history - binder was its
> > only user. Task::euid() obtains the objective effective UID - it looks
> > at the credentials of the task for purposes of acting on it as an
> > object, but then accesses the effective UID (which the credentials.7 man
> > page describes as "[...] used by the kernel to determine the permissions
> > that the process will have when accessing shared resources [...]").
> >
> > For context:
> > Arguably, binder's use of task_euid() is a theoretical security problem,
> > which only has no impact on Android because Android has no setuid binaries
> > executable by apps.
> > commit 29bc22ac5e5b ("binder: use euid from cred instead of using task")
> > originally fixed that by removing that only user of task_euid(), but the
> > fix got reverted in commit c21a80ca0684 ("binder: fix test regression
> > due to sender_euid change") because some Android test started failing.
> > It was since fixed again by commit 65b672152289 ("binder: use
> > current_euid() for transaction sender identity"), which uses
> > current_euid() instead.
> >
> > Signed-off-by: Jann Horn <jannh at google.com>
> > Reviewed-by: Gary Guo <gary at garyguo.net>
> > Signed-off-by: Alice Ryhl <aliceryhl at google.com>
> > ---
> > Originally sent as:
> > https://lore.kernel.org/r/20260212-rust-uid-v1-1-deff4214c766@google.com
> > ---
> >  rust/kernel/task.rs | 9 ++++++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
>
> Merged into lsm/dev, thanks!

Thanks!



More information about the Linux-security-module-archive mailing list