An Admin-Capability-Holding User Can 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 (Vault + Schema + XML + Index + Merry + property-change dispatcher), an admin verb in an application-tier daemon that calls a private capability-check helper at the public-LFUN entry accepts the call when the actor holds an admin-token covering the target room and action. The dispatch shape is: a boot-time test driver clones three users and one room, attaches a per-room "kick" admin-token to one user via admin->grant_admin(nil, holder, room, ({ "kick" })), then calls admin->kick(holder, target, room). The capability check walks the holder's chat-user.admin-tokens list, matches the token by query_room() and query_actions(), and returns silently; the verb proceeds by calling chat::leave_room(target, room), which removes the target from chat-room.member-list and removes the room from the target's chat-user.room-subscriptions. The test driver asserts both removals and writes a CAP-ACCEPT OK sentinel to its result file. The same LFUN that rejected the no-token actor in the paired Observation accepts the token-holding 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 from the eOSContinuum/eOS-kernellib examples/chat-app/) overlaid at the isolated runtime staging tree's src/usr/Chat/.

Setup (verifiable from repo state):

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

private
void _check_admin_token(object actor, object room, string action)
{
    mixed *tokens;
    mixed token;
    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++) {
        token = tokens[i];
        if (!token) continue;
        if (token->query_room() != room && token->query_room() != nil) {
            continue;
        }
        if (member(action, token->query_actions())) {
            return;
        }
    }
    error("admin: actor " + ... + " not authorized for " + action + " ...");
}

void kick(object actor, object target, object room)
{
    _check_admin_token(actor, room, "kick");
    if (!target) error("kick: nil target");
    if (!room) error("kick: nil room");
    CHAT_DAEMON->leave_room(target, room);
}

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.

The Chat domain's initd compiled obj/room, obj/user, data/admin_token, sys/chat, sys/admin, and sys/test; the deferred call_out("setup_and_run", 0) from sys/test::create() fired after every per-domain initd had returned.

Phase 2 smoke transcript (the load-bearing portion of the sentinel result log after the cold-boot completes):

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

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

  1. grant_admin(nil, carol, room_a, ({ "kick" })) returns a non-nil token (the LWO instantiation and attach-to-subject path succeeded).
  2. admin->kick(carol, alice, room_a) returns without throwing (the capability check matched).
  3. member(alice, room_a->query_members()) returns false (the kick removed alice from the room's member list).
  4. member(room_a, alice->query_subscriptions()) returns false (the kick removed the room from alice's subscriptions).

All four assertions ran inside catch{} blocks. The boot log carries no [caught] annotation for the kick verb during phase 2 (the boot log's [caught] annotations are limited to phase 1's deliberate rejection); the verb completed normally.

Process identity check: a single DGD process served all four assertions in one boot. The boot log records no ** System halted. entry between phases. No statedump was invoked. No admin_console session was opened. The runtime instance carrying the assertions is the same one initialized at ** Initialization complete..

What the evidence establishes:

What the evidence does not establish:

What Would Revise It

Sources

Relations