key_alloc(9)

💅 key_alloc(9) — from the Kernel API Manual, bestie

okay so picture this: you're deep in ./security/keys land and you need a brand new key. that's literally this function. welcome 🫶

---

✨ NAME ✨

key_alloc — allocate a key of the specified type. that's it, that's the whole gig 💖

---

🌸 SYNOPSIS 🌸

struct key * key_alloc (struct key_type *type , const char *desc ,
       kuid_t uid , kgid_t gid , const struct cred *cred , key_perm_t perm ,
       unsigned long flags , struct key_restriction *restrict_link );

---

🎀 ARGUMENTS 🎀

• type — the type of key you're allocating. gotta pick one, bestie.
• desc — the key description, which is the thing that lets the key be searched out later. iykyk, naming matters.
• uid — the owner of the new key.
• gid — the group ID that's used for the new key's group permissions.
• cred — the credentials that specify the UID namespace.
• perm — the permissions mask of the new key.
• flags — flags that specify quota properties.
• restrict_link — optional link restriction for new keyrings. optional, so like... no pressure, but also read the description 👀

---

🦋 DESCRIPTION 🦋

So you call this and it allocates a key of the specified type with all the attributes you handed over. The key comes back to you in an uninstantiated state — which means the caller (that's you, hun) needs to instantiate the key before returning. don't just walk away with a half-done key, that's not the vibe 😭

The restrict_link structure — if it's not NULL — will be freed when the keyring is destroyed, so it must be dynamically allocated. like, actually dynamically allocated. no stack tricks, no cap. 💀

The user's key count quota gets updated to reflect the creation of the key, and the user's key data quota has the default for the key type reserved. The instantiation function should amend this as necessary. If there isn't enough quota available, you'll get -EDQUOT back. rude but fair.

The LSM security modules can prevent a key from being created, and in that case you get -EACCES back. it's giving bouncer-at-the-club energy 🚫

Returns a pointer to the new key if it worked, and an error code otherwise. slay.

⚠️ real talk: note that the caller needs to ensure the key type isn't uninstantiated. Internally this can be done by locking key_types_sem. Externally, it can be done by either never unregistering the key type, or by making sure key_alloc calls don't race with module unloading. that last one is a whole vibe check you do not want to fail, fr fr. 🔥

---

👑 SEE ALSO 👑

Kernel file ./security/keys/key.c — and also these iconic siblings: key_payload_reserve(9), key_instantiate_and_link(9), key_reject_and_link(9), key_put(9), key_create_or_update(9), key_create(9), key_update(9), key_revoke(9), key_invalidate(9), generic_key_instantiate(9), register_key_type(9), unregister_key_type(9). go read them, they ate 💅

---

and that's the whole page, bestie! 🎀 this came out of ./security/keys, dated October 2026, and yes it's key_alloc(9) — the main character of this particular manpage. mwah 💖✨