smk_access(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… smk_access(9) β€” like, the kernel API manual page, bestie πŸ’…

okay so real talk, this is smk_access(9) from the "Kernel API Manual" and it's genuinely one of those little functions that carries the whole vibe of Smack access control. no cap. let's get into it ✨


πŸŽ€ NAME πŸŽ€

smk_access β€” determine if a subject has a specific access to an object

like, does this thing get to touch that thing? that's the whole question. slay. 🫢


✨ SYNOPSIS ✨

int smk_access (struct smack_known *subject , struct smack_known *object
, int request , struct smk_audit_info *a );

four arguments, one int back, iconic signature honestly πŸ‘‘


πŸ¦‹ ARGUMENTS πŸ¦‹

  • subject β€” a pointer to the subject's Smack label entry. so, the one doing the thing πŸ’β€β™€οΈ
  • object β€” a pointer to the object's Smack label entry. the one having the thing done to it πŸŽ€
  • request β€” the access requested, in "MAY" format. yes, capital-M "MAY", that's literally what the manpage says, iykyk 🌸
  • a β€” a pointer to the audit data. the receipts, basically πŸ“

πŸ’– DESCRIPTION πŸ’–

so what does it actually do? this function looks up the subject/object pair in the access rule list and returns 0 if the access is permitted, non zero otherwise. that's it. that's the whole function and honestly? it ate. πŸ”₯

lowkey important: 0 = yes bestie you're allowed, non zero = nope, not today πŸ’€

also worth knowing: Smack labels are shared on smack_list β€” so the label entries aren't special little unique snowflakes, they're shared, which is the whole point of passing pointers to them around 🧚


🌈 SEE ALSO 🌈

the whole friend group, fr fr β€” this all lives in the Kernel file ./security/smack/smack_access.c:

go read all of them, they're all main characters in their own way πŸ’œ


kisses, this page ships out of ./security/smack and it's dated October 2026 β€” so yeah, bookmark it, screenshot it, send it to the group chat, mwah πŸŽ€πŸ’‹

πŸ“¦ where this page comes from