All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Onur Özkan" <work@onurozkan.dev>
To: Arnav Sharma <arnav4324@gmail.com>
Cc: ojeda@kernel.org, paul@paul-moore.com,
	"Serge Hallyn" <sergeh@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	linux-security-module@vger.kernel.org,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rust: cred: add safe abstractions for capable() and ns_capable()
Date: Thu,  7 May 2026 09:04:49 +0300	[thread overview]
Message-ID: <20260507060452.5270-1-work@onurozkan.dev> (raw)
In-Reply-To: <20260506204913.26022-1-arnav4324@gmail.com>

On Thu, 07 May 2026 02:19:13 +0530
Arnav Sharma <arnav4324@gmail.com> 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.

Do we have any users who need this? What's the use case and where will this be
used?

-Onur

> 
> Signed-off-by: Arnav Sharma <arnav4324@gmail.com>
> ---
>  rust/kernel/cred.rs | 79 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 79 insertions(+)
> 
> diff --git a/rust/kernel/cred.rs b/rust/kernel/cred.rs
> index ffa156b9df37..6525b52b81ae 100644
> --- a/rust/kernel/cred.rs
> +++ b/rust/kernel/cred.rs
> @@ -90,3 +90,82 @@ unsafe fn dec_ref(obj: core::ptr::NonNull<Credential>) {
>          unsafe { bindings::put_cred(obj.cast().as_ptr()) };
>      }
>  }
> +
> +/// Checks whether the current task has the given capability in the init user namespace.
> +///
> +/// This function tests whether the current task has the specified POSIX capability available for
> +/// use. The check is performed against the initial user namespace (`init_user_ns`).
> +///
> +/// When the check succeeds, the kernel sets the `PF_SUPERPRIV` flag on the current task. This
> +/// marks the task as having used superuser privileges, which is visible in process accounting
> +/// and auditing.
> +///
> +/// The capability constants are available as `bindings::CAP_*` values (for example,
> +/// [`bindings::CAP_NET_ADMIN`], [`bindings::CAP_SYS_ADMIN`]). These constants are defined in
> +/// `include/uapi/linux/capability.h`.
> +///
> +/// This function must be called from task (process) context only. Calling it from a context where
> +/// there is no valid `current` task (such as hard interrupt context) is not permitted.
> +///
> +/// # Preconditions
> +///
> +/// `cap` must be a valid capability constant in the range `[0, CAP_LAST_CAP]`.
> +/// Passing a value outside this range is a programming error and will trigger
> +/// a kernel `BUG()`.
> +///
> +/// C header: [`include/linux/capability.h`](srctree/include/linux/capability.h)
> +///
> +/// # Examples
> +///
> +/// ```
> +/// use kernel::bindings;
> +/// use kernel::cred::capable;
> +///
> +/// if !capable(bindings::CAP_SYS_ADMIN) {
> +///     return Err(EPERM);
> +/// }
> +/// # Ok::<(), Error>(())
> +/// ```
> +#[inline]
> +pub fn capable(cap: u32) -> bool {
> +    // SAFETY: `capable()` is safe to call from task context. It checks `current_cred()` against
> +    // the init user namespace and returns whether the specified capability is granted.
> +    unsafe { bindings::capable(cap as i32) }
> +}
> +
> +/// Checks whether the current task has the given capability in the specified user namespace.
> +///
> +/// This is the namespace-aware variant of [`capable`]. It tests whether the current task has the
> +/// specified capability in the given user namespace, rather than in the init user namespace.
> +///
> +/// This function is relevant for code that must respect user namespace boundaries (for example,
> +/// operations inside unprivileged containers). For most driver code that is not namespace-aware,
> +/// [`capable`] is the correct function to use instead.
> +///
> +/// Like [`capable`], this function sets `PF_SUPERPRIV` on the current task when the check
> +/// succeeds, and it must be called from task context only.
> +///
> +/// # Preconditions
> +///
> +/// `cap` must be a valid capability constant in the range `[0, CAP_LAST_CAP]`.
> +/// Passing a value outside this range is a programming error and will trigger
> +/// a kernel `BUG()`.
> +///
> +/// C header: [`include/linux/capability.h`](srctree/include/linux/capability.h)
> +///
> +/// # 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 {
> +    // SAFETY: The caller guarantees that `ns` is a non-null, valid pointer to a fully initialized
> +    // `struct user_namespace` that remains valid for the duration of this call.
> +    // `ns_capable()` checks `current_cred()` against the provided namespace and returns whether
> +    // the specified capability is granted.
> +    unsafe { bindings::ns_capable(ns, cap as i32) }
> +}
> +
> -- 
> 2.43.0
> 

  reply	other threads:[~2026-05-07  6:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06 20:49 [PATCH] rust: cred: add safe abstractions for capable() and ns_capable() Arnav Sharma
2026-05-07  6:04 ` Onur Özkan [this message]
2026-05-07  7:22 ` Alice Ryhl
2026-05-13 12:53 ` kernel test robot
2026-05-13 15:39 ` kernel test robot
     [not found] <CACeWta-RVTqcmLVmLTJ7yLrStjrLEyL_oYpG8QLAcy7sEyKmCA@mail.gmail.com>
2026-05-15 19:07 ` Miguel Ojeda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260507060452.5270-1-work@onurozkan.dev \
    --to=work@onurozkan.dev \
    --cc=a.hindborg@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=arnav4324@gmail.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=paul@paul-moore.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=sergeh@kernel.org \
    --cc=tmgross@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.