A Regular User Cannot Kick from a Chat Room

Claim

In the eOS-Harness MVA running against DGD 1.7.9 plus the eOSContinuum/eOS-kernellib feature/cohesive-lift branch carrying the kernel-layer cohesive lift, an admin verb in an application-tier daemon that calls a private capability-check helper at the public-LFUN entry rejects the call when the actor holds no admin-token covering the target room and action. The dispatch shape is: a boot-time test driver clones three users and one room, then has a no-token user call admin->kick(actor, target, room). The capability check walks the actor's empty chat-user.admin-tokens list, finds no match, and calls error(...). The error propagates up through kick's frame and lands in the test driver's catch{}. The verb body never runs past the check; the target's chat-room.member-list membership is unchanged. The test driver asserts the unchanged membership and writes a CAP-REJECT OK sentinel to its result file. The boot log records the error with a [caught] annotation -- DGD logs every error regardless of catch{} so the platform retains a trace, with the caught/uncaught distinction in the suffix. The same kick LFUN that accepts the token-holding actor in the paired Observation rejects the no-token actor; the gate is parameterized on the actor's token holdings, not on the caller's program or the LFUN's name.

Grounds

This is an Empirical Observation. The grounds are a captured cold-boot smoke run 2026-05-27 against the live MVA demonstration instance with examples/chat-app/ deployed at the isolated runtime staging tree's src/usr/Chat/. Phase 1 of the boot-time test driver exercises the rejection path; phase 2 (the paired positive Observation) exercises the acceptance path. Both phases share the same cold-boot DGD process.

Setup (verifiable from repo state):

Load-bearing source (the rejection branch in examples/chat-app/sys/admin.c):

private
void _check_admin_token(object actor, object room, string action)
{
    mixed *tokens;
    int i, sz;

    if (!actor) {
        error("admin: nil actor for " + action);
    }
    tokens = actor->query_admin_tokens();
    sz = sizeof(tokens);
    for (i = 0; i < sz; i++) {
        /* ... match logic; falls through if no token matches ... */
    }
    error("admin: actor " + (actor->query_chat_name() ? actor->query_chat_name() : "(unnamed)") +
          " not authorized for " + action + " in room " +
          (room ? (room->query_id() ? room->query_id() : "(unnamed)") : "(realm)"));
}

Boot sequence: a clean cold boot against the isolated runtime staging tree, with examples/chat-app/ materialized at src/usr/Chat/ and the instance config loaded, reaching ** Initialization complete. in under one second.

** DGD 1.7.9
** Initializing...
** Initialization complete.

Phase 1 smoke transcript (the load-bearing portion of the sentinel result log):

ChatApp:test: starting
ChatApp:test: CAP-REJECT OK
ChatApp:test: CAP-ACCEPT OK

Phase 1 boot-log trace of the rejection:

** admin: actor bob not authorized for kick in room ChatApp:Room:LobbyA [caught]
                       /usr/Chat/sys/test
   58   setup_and_run         /usr/Chat/sys/test
   96 * run_tests             /usr/Chat/sys/test
                       /usr/Chat/sys/admin
   52   kick                  /usr/Chat/sys/admin
  148   _check_admin_token    /usr/Chat/sys/admin

The frame walk reads bottom-up: _check_admin_token raised the error at line 148; the error propagated up through kick at line 52; the test driver's run_tests at line 96 caught it via its catch{} block. The [caught] suffix on the error line confirms the error did not propagate to the runtime -- DGD's convention is to log every error regardless of catch{} so the platform retains a trace, with the caught/uncaught distinction in the suffix.

CAP-REJECT OK writes to the sentinel file only when:

  1. admin->kick(bob, alice, room_a) threw (the capability check rejected the call); the test driver's rejected flag was set inside catch{}.
  2. member(alice, room_a->query_members()) returned true (alice's membership in room_a was unchanged by the rejected call -- the verb body never ran).

Both assertions ran inside catch{} blocks. The driver continued to phase 2 only after phase 1's PASS.

Process identity check: the same DGD process served phase 1 and phase 2. The boot log records no ** System halted. entry between phases. No statedump was invoked. No admin_console session was opened.

What the evidence establishes:

What the evidence does not establish:

What Would Revise It

Sources

Relations