[PATCH 0/2] binder+rust_binder: use current_euid() for transaction sender identity

Jann Horn posted 2 patches 1 month, 2 weeks ago
drivers/android/binder.c              | 2 +-
drivers/android/binder/transaction.rs | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
[PATCH 0/2] binder+rust_binder: use current_euid() for transaction sender identity
Posted by Jann Horn 1 month, 2 weeks ago
Based on the discussion on
<https://lore.kernel.org/all/20260212-rust-uid-v1-1-deff4214c766@google.com/>,
here's a proposed change to binder to stop looking at objective EUIDs.

This removes the last remaining users of Task::euid() (in Rust), and the
only remaining caller to task_euid() is the now-unused Rust wrapper.

(Sidenote: It might be worth considering whether it really makes sense
to have functions like current_euid(), task_euid(), and so on in Rust -
it might be less messy to just expose current_cred() and (if necessary)
get_task_cred(), and then use the `Credential` abstraction around
`struct cred` to access the various UID/GID/... fields.)

(build-tested only.)

Signed-off-by: Jann Horn <jannh@google.com>
---
Jann Horn (2):
      binder: use current_euid() for transaction sender identity
      rust_binder: use current_euid() for transaction sender identity

 drivers/android/binder.c              | 2 +-
 drivers/android/binder/transaction.rs | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
---
base-commit: 3c4ae63073d84abee5d81ce46d86a94e9dae9c89
change-id: 20260213-binder-uid-a24ede5026a8

--  
Jann Horn <jannh@google.com>
Re: [PATCH 0/2] binder+rust_binder: use current_euid() for transaction sender identity
Posted by Gary Guo 1 month, 1 week ago
On 2026-02-13 21:37, Jann Horn wrote:
> Based on the discussion on
> <https://lore.kernel.org/all/20260212-rust-uid-v1-1-deff4214c766@google.com/>,
> here's a proposed change to binder to stop looking at objective EUIDs.
> 
> This removes the last remaining users of Task::euid() (in Rust), and 
> the
> only remaining caller to task_euid() is the now-unused Rust wrapper.
> 
> (Sidenote: It might be worth considering whether it really makes sense
> to have functions like current_euid(), task_euid(), and so on in Rust -
> it might be less messy to just expose current_cred() and (if necessary)
> get_task_cred(), and then use the `Credential` abstraction around
> `struct cred` to access the various UID/GID/... fields.)
> 
> (build-tested only.)
> 
> Signed-off-by: Jann Horn <jannh@google.com>

Acked-by: Gary Guo <gary@garyguo.net>

> ---
> Jann Horn (2):
>       binder: use current_euid() for transaction sender identity
>       rust_binder: use current_euid() for transaction sender identity
> 
>  drivers/android/binder.c              | 2 +-
>  drivers/android/binder/transaction.rs | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> ---
> base-commit: 3c4ae63073d84abee5d81ce46d86a94e9dae9c89
> change-id: 20260213-binder-uid-a24ede5026a8
> 
> --
> Jann Horn <jannh@google.com>
Re: [PATCH 0/2] binder+rust_binder: use current_euid() for transaction sender identity
Posted by Alice Ryhl 1 month, 2 weeks ago
On Fri, Feb 13, 2026 at 10:37:29PM +0100, Jann Horn wrote:
> Based on the discussion on
> <https://lore.kernel.org/all/20260212-rust-uid-v1-1-deff4214c766@google.com/>,
> here's a proposed change to binder to stop looking at objective EUIDs.
> 
> This removes the last remaining users of Task::euid() (in Rust), and the
> only remaining caller to task_euid() is the now-unused Rust wrapper.

Any chance you could include a patch to remove the now-unused method?

> (Sidenote: It might be worth considering whether it really makes sense
> to have functions like current_euid(), task_euid(), and so on in Rust -
> it might be less messy to just expose current_cred() and (if necessary)
> get_task_cred(), and then use the `Credential` abstraction around
> `struct cred` to access the various UID/GID/... fields.)

We could add a cred() method to CurrentTask and do this:

	current!().cred().euid()

> Signed-off-by: Jann Horn <jannh@google.com>

Reviewed-by: Alice Ryhl <aliceryhl@google.com>