restrict_li...eyring_chain(9)

okay bestie, welcome to the restrict_li...eyring_chain(9) page from the Kernel API Manual 💅✨ this one is all about restricting additions to a ring of public keys, and yes it's giving kernel-keyring security realness 🔐🦋

🌸 NAME 🌸

restrict_link_by_key_or_keyring_chain — restrict additions to a ring of public keys using the restrict_key information stored in the ring. periodt 💖

✨ SYNOPSIS ✨

int restrict_link_by_key_or_keyring_chain (struct key *dest_keyring ,
const struct key_type *type , const union key_payload *payload , struct
key *trusted );

🎀 ARGUMENTS 🎀

• dest_keyring — the keyring being linked to, bestie 💫
• type — the type of key being added 👑
• payload — the payload of the new key 🍓
• trusted — a key or ring of keys that can be used to vouch for the new cert 🫶

💜 DESCRIPTION 💜

so here's the vibe: it checks the new certificate against the key or keys passed in the data parameter, and also against the keys already linked to the destination keyring 🔍✨ if one of those is the signing key and validates the new certificate, then it marks the new certificate as being ok to link 💅✅

and the returns are literally:

• 0 if the new certificate was accepted 🎉
• -ENOKEY if we couldn't find a matching parent certificate in the trusted list 😭
• -EKEYREJECTED if the signature check fails 💀
• -ENOPKG if the signature uses unsupported crypto 🙈
• or some other error if there is a matching certificate but the signature check cannot be performed 🫠

🌈 SEE ALSO 🌈

• Kernel file ./crypto/asymmetric_keys/restrict.c 🧚
• restrict_link_by_signature(9)
• restrict_link_by_ca(9)
• restrict_link_by_digsig(9)
• restrict_link_by_key_or_keyring(9)

mwah 💖 this slay little page comes from ./crypto/asymmetric_keys, dated October 2026, and it's literally the restrict_li...eyring_chain(9) page — no cap, that's the sign-off 🎀💫