Messages in this thread |  | | Date | Thu, 7 May 2026 07:22:31 +0000 | | Subject | Re: [PATCH] rust: cred: add safe abstractions for capable() and ns_capable() | | From | Alice Ryhl <> |
| |
On Thu, May 07, 2026 at 02:19:13AM +0530, Arnav Sharma wrote: > The capable() function is the primary privilege gate in the Linux kernel, > used to check if the current task possesses a specific POSIX capability. > While bindings for capable() and ns_capable() exist, there are currently > no safe Rust abstractions for them. > > Introduce safe Rust wrappers for capable() and ns_capable() in the > kernel::cred module. These functions validate that the requested > capability is within the valid [0, CAP_LAST_CAP] bounds before calling > into the C side, ensuring that safe Rust code cannot inadvertently > trigger a kernel BUG() on invalid inputs. > > The abstractions take a `u32` parameter to ergonomically match the > generated `bindings::CAP_*` constants without requiring explicit caller > casts. > > Signed-off-by: Arnav Sharma <arnav4324@gmail.com>
I have the same question about what the use-case for this is.
> +/// # Safety > +/// > +/// The caller must ensure that: > +/// > +/// - `ns` is a non-null pointer to a fully initialized `struct user_namespace`. > +/// - The `user_namespace` pointed to by `ns` remains valid and is not freed for > +/// the duration of this call. > +#[inline] > +pub unsafe fn ns_capable(ns: *mut bindings::user_namespace, cap: u32) -> bool {
I would add a UserNamespace struct so that this raw pointer could be avoided, before I add this method.
Alice
|  |