KEYCTL_ASSUME_AUTHORITY(2const)

💅 KEYCTL_ASSUME_AUTHORITY — the keyctl const, bestie edition ✨

okay so this is a page from section 2const of the Unix manual — the keyctl const girlies — and it's literally all about assuming the authority to instantiate a key. yes that's the whole vibe. let's get into it 🫶

---

✨ NAME ✨

KEYCTL_ASSUME_AUTHORITY — bestie, it's giving "assume the authority to instantiate a key" 💅

---

📚 LIBRARY 📚

Standard C library (libc, -lc) — yep, the classic 🌸

---

🎀 SYNOPSIS 🎀

#include <linux/keyctl.h>  /* Definition of KEY* constants */
#include <sys/syscall.h>   /* Definition of SYS_* constants */
#include <unistd.h>

long syscall(SYS_keyctl, KEYCTL_ASSUME_AUTHORITY, key_serial_t key);

literally just one lil syscall, no cap 🦋

---

🌈 DESCRIPTION 🌈

So what this does: it lets the calling thread assume — or divest — the authority to instantiate a key. main character energy for threads fr fr 👑

The key argument is doing one of two things:

• it's a nonzero key ID, in which case you're assuming authority,
• or it's the value 0, in which case you're divesting authority. bye bestie 💀

If key is nonzero, then it specifies the ID of an uninstantiated key that you wanna take authority over. once you've got that, you can instantiate it using any one of these:

• KEYCTL_INSTANTIATE(2const)
• KEYCTL_INSTANTIATE_IOV(2const)
• KEYCTL_REJECT(2const)
• KEYCTL_NEGATE(2const)

and here's the cute part: once the key has been instantiated, the thread is automatically divested of its authority to instantiate the key. it just… lets go. growth. ✨

Now, the rules. Authority over a key can be assumed only if the calling thread has, present in its keyrings, the authorization key associated with the specified key. in other words — and I'm quoting the vibe here — the KEYCTL_ASSUME_AUTHORITY operation is available only from a request-key(8)-style program. see request_key(2) if you wanna know how this operation is actually used. also: the caller must have search permission on the authorization key. no permission, no authority. 🚫

If the specified key has a matching authorization key, then the ID of that key gets returned. and you can read the authorization key with KEYCTL_READ(2const) to grab the callout information that was passed to request_key(2). handy 🍓

If the ID given in key is 0, then the currently assumed authority is cleared (divested), and the value 0 is returned. clean slate, we love to see it 💖

So why does this mechanism even exist? Because KEYCTL_ASSUME_AUTHORITY lets a program like request-key(8) assume the necessary authority to instantiate a brand-new uninstantiated key that got created as a consequence of a call to request_key(2). for more info, go read request_key(2) and the kernel source file Documentation/security/keys/request-key.rst. iykyk 📖

---

🔥 RETURN VALUE 🔥

On success, you get either:

• 0 — if the ID you gave was 0, or
• the ID of the authorization key matching the specified key — if you provided a nonzero key ID.

On error, -1 is returned, and errno is set to indicate the error. classic. 😭

---

🌸 VERSIONS 🌸

There's a wrapper for this in the libkeyutils library: keyctl_assume_authority(3). so if you don't wanna raw-dog the syscall, you don't have to 🧚

---

⭐ STANDARDS ⭐

Linux. that's it. that's the standard. periodt 💅

---

👑 HISTORY 👑

Linux 2.6.16. an icon, been around forever 🌈

---

💜 SEE ALSO 💜

• keyctl(2)
• keyctl_assume_authority(3)

---

lowkey reminder bestie: this authority thing only works if you're a request-key(8)-style program with the authorization key in your keyrings and search permission on it. no shortcuts, no vibes-based access 🚨

okay that's the whole page!! mwah 💋 this was Linux man-pages 6.20, dated 2026-02-08 — thanks for reading, ily, go instantiate something responsibly 🎀✨