SECURELEVEL_GT(9)

πŸ’… SECURELEVEL_GT πŸ’…

okay bestie so this is a section 9 manpage from the Kernel Developer's Manual, and we're talking about securelevel_gt, securelevel_ge β€” the girlies that test the active securelevel. πŸŽ€


✨ NAME ✨

securelevel_gt, securelevel_ge β€” test active securelevel πŸ”₯


πŸ¦‹ SYNOPSIS πŸ¦‹

#include <sys/types.h>
#include <sys/proc.h>

int
securelevel_gt(struct ucred *cr, int level);

int
securelevel_ge(struct ucred *cr, int level);

🌸 DESCRIPTION 🌸

So basically these functions test the active security level against the level you hand them. Iconic behaviour, honestly.

Here's the lil plot twist: if the calling credential cr was imprisoned by the jail(2) system call, and it has a different security level set than the host environment, then the security level with the highest value is the one that gets used. Not the lowest. Not the average. The highest. periodt. πŸ‘‘

Now the two functions, one at a time:

  • securelevel_gt() β€” evaluates whether or not the active security level is greater than the supplied level. strictly greater, no equals allowed, we're picky πŸ’…
  • securelevel_ge() β€” evaluates whether or not the active security level is greater than or equal to the supplied level. this one's chill, equality counts 🫢

πŸ’– RETURN VALUES πŸ’–

These functions return EPERM if the condition evaluated to true, and 0 otherwise.

no cap, that's a little unhinged of them β€” returning an error code for "yes" β€” but that's just the vibe here. 😭

🌈 SEE ALSO 🌈


and that's the whole page bestie, go forth and vibe check those securelevels πŸ’œ

this was Debian's June 2, 2007 edition of SECURELEVEL_GT(9) from the Kernel Developer's Manual β€” mwah, iconic, no notes πŸ’–βœ¨

πŸ“¦ where this page comes from