P_CANDEBUG(9)

💖 P_CANDEBUG 💖

okay so bestie, this is a kernel developer's manual page, and we're talking about p_candebug — literally the function that answers the question every nosy process asks: can I peek at you tho? 👀✨

---

🌸 NAME 🌸

p_candebug — determine debuggability of a process

like, is this process debug-able or not, that's the whole vibe check 🫶

---

✨ SYNOPSIS ✨

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

int
p_candebug(struct thread *td, struct proc *p);

two args, one int back, no drama 💅

---

🦋 DESCRIPTION 🦋

This function can be used to determine if a given process p is debuggable by the thread td.

that's it. that's the whole thing. you hand it a thread and a process, and it tells you whether that thread is allowed to debug that process. no cap. 🔥

---

🎀 SYSCTL VARIABLES 🎀

These sysctl(8) variables directly influence the behaviour of p_candebug() — like, they are the main characters here, they run the show 👑

• kern.securelevel — Debugging of the init process is not allowed if this variable is 1 or greater. so if you cranked this up, hands off init, bestie, she's protected 🛡️
• security.bsd.unprivileged_proc_debug — Must be set to a non-zero value to allow unprivileged processes access to the kernel's debug facilities. if this is 0, unprivileged girlies are locked out of the debug party 🙈

---

⭐ RETURN VALUES ⭐

The p_candebug() function returns 0 if the process denoted by p is debuggable by thread td, or a non-zero error return value otherwise.

so: 0 = yes queen, go debug 💖, non-zero = nope, and the number tells you why 😭

---

💀 ERRORS 💀

• [EACCESS] — The MAC subsystem denied debuggability.
• [EAGAIN] — Process p is in the process of being exec()'ed. like she's mid-transformation, give her a sec 🧚
• [EPERM] — Thread td lacks super-user credentials and process p is executing a set-user-ID or set-group-ID executable.
• [EPERM] — Thread td lacks super-user credentials and process p's group set is not a subset of td's effective group set.
• [EPERM] — Thread td lacks super-user credentials and process p's user IDs do not match thread td's effective user ID.
• [EPERM] — Process p denotes the initial process initproc() and the sysctl(8) variable kern.securelevel is greater than zero.
• [ESRCH] — Process p is not visible to thread td as determined by cr_seeotheruids(9) or cr_seeothergids(9).
• [ESRCH] — Thread td has been jailed and process p does not belong to the same jail as td.
• [ESRCH] — The MAC subsystem denied debuggability.

ngl there's a whole lot of [EPERM] up in here and yes, they are different reasons, don't merge them in your head, bestie, each one is its own little lore drop 📖

---

🌈 SEE ALSO 🌈

jail(2), sysctl(8), cr_seeothergids(9), cr_seeotheruids(9), mac(9), p_cansee(9), prison_check(9)

go read those too, iykyk 📚✨

---

and that's the whole page, periodt 💅

this one came from the Debian crew, dated November 19, 2006 — yeah she's an oldie but a goodie, vintage kernel lore fr fr 🎀🦋