cleanup: comments in capabilities modules, default capabilities.toml, login
This commit is contained in:
1 parent
2eee6696ef
commit
93894b8fe5
4 files changed
+1
-50
No files matched your search
@@ -12,22 +12,7 @@
|
||||
#include <CppLib/Spinlock.hpp>
|
||||
|
||||
// A process that lacks an eligible capability can ask the user for it the
|
||||
// first time a syscall needs it. The request goes to the session's consent
|
||||
// agent (the desktop, which holds CAP_COMPOSITOR), which answers from its
|
||||
// stored decisions or by showing a prompt.
|
||||
//
|
||||
// This keeps both capability invariants:
|
||||
// 1. Authority only narrows down the process tree. A grant is bounded by the
|
||||
// process's consent ceiling -- what its parent could have delegated to it
|
||||
// at spawn -- and by the agent's own delegable set, and is only ever added
|
||||
// to the effective set. Consent defers a delegation; it never exceeds one.
|
||||
// 2. Capabilities are kernel-owned. The kernel identifies the program by the
|
||||
// path it loaded, never by a user name, and tells the agent whether that
|
||||
// path is protected by CAP_SYSTEM_IMAGE (only then may it be remembered).
|
||||
//
|
||||
// Lock order: g_lock, then the scheduler lock (inside the Sched helpers).
|
||||
// Nothing takes g_lock while holding the scheduler lock; the wait predicate
|
||||
// that runs under the scheduler lock only reads atomics.
|
||||
// first time a syscall needs it.
|
||||
|
||||
namespace Sched::Consent {
|
||||
|
||||
|
||||
Reference in new issue
Block a user