user-keyring(7)

💖 user-keyring(7) 💖

okay bestie, so this is a page from the Miscellaneous Information Manual, section 7 — user-keyring(7). it's giving "the keyring that belongs to you", and honestly? iconic. let's get into it 🫶

✨ NAME ✨

user-keyring — the per-user keyring, aka your very own keyring, no cap 💅

🌸 DESCRIPTION 🌸

so the user keyring is, like, a keyring whose whole job is to anchor keys on behalf of a user. every single UID the kernel deals with gets its own user keyring, and that keyring is shared by all the processes that have that UID. yes, all of them. they're passing the aux cord around. 🎀

the user keyring has a name (we call it a description around here) shaped like this: _uid.<UID> — where <UID> is the user ID of the corresponding user. that's it, that's the naming scheme, she's simple and she's correct ✨

here's the tea on how she comes into existence: the user keyring is tied to the record the kernel keeps for that UID. it pops into existence the first time anything tries to access either the user keyring, the user-session-keyring(7), or the session-keyring(7). and once she's here, the keyring stays pinned in existence for as long as there are processes running with that real UID, or files opened by those processes are still open. (also, you can pin it indefinitely by linking it into another keyring — main character energy, she refuses to leave 🫶)

typically, the user keyring gets created by pam_keyinit(8) when a user logs in. slay.

big important thing bestie: the user keyring is not searched by default by request_key(2). when pam_keyinit(8) creates a session keyring, it adds a link to the user keyring inside it, so that the user keyring does get searched when the session keyring is searched. so like, she's not out here getting noticed on her own — she gets noticed through her friend 😭

there's a special serial number value, KEY_SPEC_USER_KEYRING, defined so you can use it in lieu of the actual serial number of the calling process's user keyring. very convenient, we love a shortcut ✨

and from the keyctl(1) utility, you can use '@u' instead of a numeric key ID in much the same way. yes queen, abbreviated 💅

user keyrings are independent of clone(2), fork(2), vfork(2), execve(2), and _exit(3) — the only exception being that the keyring gets destroyed when the UID record is destroyed, which happens when the last process pinning it exits. so like, she's not affected by your forking and exec-ing, she's just out here existing, but when the last one leaves the party, she's gone 💀

if it's necessary for a key associated with a user to exist beyond the UID record being garbage collected — for example, for use by a cron(8) script — then you should use the persistent-keyring(7) instead. do not come for the user keyring for that, she is not the one, periodt.

oh and one more: if a user keyring does not exist when it is accessed, it will be created. she materializes. she is always available 🦋

---

👑 SEE ALSO 👑

• keyctl(1)
• keyctl(3)
• keyrings(7)
• persistent-keyring(7)
• process-keyring(7)
• session-keyring(7)
• thread-keyring(7)
• user-session-keyring(7)
• pam_keyinit(8)

---

and that's the whole vibe bestie 💜 this was brought to you by Linux man-pages 6.20, dated 2026-06-05 — go forth and know your keyrings, i'm obsessed with you 🌈⭐