Re: [PATCH] rust: task: clarify comments on task UID accessors

[Jann Horn]

On Fri, Feb 13, 2026 at 9:53 AM Gary Guo <gary@xxxxxxxxxxx> wrote:
> On Fri Feb 13, 2026 at 2:00 AM CST, Jann Horn 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() - binder is 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.
>
> If there's no setuid binary, then the `task_euid` can also just be replaced with
> `task_uid`?

That would still be wrong for binder's usecase though.

> > commit 29bc22ac5e5b ("binder: use euid from cred instead of using task")
> > 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.
>
> What exactly is relying on the current behaviour? It'll better to fix that and
> remove `task_euid` completely as I find "objective effective UID" quite
> confusing, even with disclaimer that it shouldn't be used.

I agree with that; I don't know what that failing test was. (Todd
would probably know.) My understanding is:

In the current version, the ->sender_euid reported to a transaction's
recipient is the EUID of the sending process *at the time the
transaction is received by the recipient*. (This is wrong if the
sending process changed credentials after sending the transaction, and
especially dangerous if the sending process went through a setuid
execution in the meantime.)

With the reverted fix, the ->sender_euid reported to the recipient was
the EUID of the sending process *when it opened /dev/binder*. (That is
secure, and capturing credentials at open() time is a standard
mechanism in Linux, but it might be surprising to userspace code that
calls seteuid() between opening /dev/binder and sending a transaction.
I guess that's probably what that failing test was about.)

Probably the right fix would be to capture the current_euid() in the
sending process when it sends a transaction.