C.W.K.
Stream
Lesson 04 of 04 · published

Reachable Is Not Allowed

~9 min · reachable-is-not-allowed, volume-owner, no-fabricated-credentials

Level 0Lone Machine
0 XP0/37 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"'I can reach it' and 'I'm allowed to change it' are two different sentences. Systems that confuse them break in production."

Reachability is a network fact; authority is a capability fact

That you can open an SSH session to a machine tells you the network let you in. It says nothing about whether that session can unlock the login Keychain, raise a GUI approval dialog, or write as the volume owner. Reachable and authorized are different axes, and treating a green connection as a blanket permission is the root of a whole family of failures.

Headless never assumes

So a launchd or SSH executor must not assume login-Keychain, GUI-session, or volume-owner access. Those are declared capabilities it may or may not have — never defaults it helps itself to. The safe posture is: assume the least, declare what you actually hold, and let preflight decide whether that's enough.

Volume-owner is the sharpest case

The clearest example is a macOS system update. An update executor can stage and resume typed work, but it never stores or invents volume-owner authorization; the bootstrap-token and interactive-owner paths stay explicit capabilities. It doesn't bypass Apple's rules, and it doesn't tuck away a credential to make a future run easier. If the envelope lacks the authority, the honest answer is to stop and say so — not to manufacture the missing right.

The gap is handled, never papered over

When an envelope can't satisfy a step, there are exactly two acceptable moves: send the target to needs_attention, or delegate to a compatible executor. Never loop credential prompts. Never copy a secret into the operation to smuggle it across the gap. Never let host identity stand in for credential availability. The mismatch is a fact to report, not a wall to tunnel under.

Reachable is not allowed. Prove the capability; never infer it from a successful connection — the connection only proves the door opened, not that it holds the key.

Code

Reachable, but that proves nothing about authority·python
if reachable(host):
    # WRONG -- infer authority from a successful connection:
    #   run_privileged_step(host)   # assumes Keychain/GUI/volume-owner it may not have

    # RIGHT -- reachability only earns you a preflight, not a mutation:
    caps = executor_for(host).capabilities
    if step.requires <= caps:
        executor.run(step)
    else:
        target.state = "needs_attention"   # or delegate; never fabricate the missing right

# A signed OS-update executor stages/resumes work but NEVER stores or
# invents volume-owner authorization. If it lacks the right, it stops --
# it does not manufacture one to keep going.

External links

Exercise

Find a place in your own setup where 'I can connect' quietly became 'I can do anything' — a script that assumes sudo because it can SSH in, a CI job that assumes a secret is present because the host is reachable. Rewrite it to prove the capability first, and decide what it should do when the capability is genuinely absent (stop and report, or hand off) — without ever caching a secret to force it through.
Hint
The honest failure is 'needs a human / needs a different door,' surfaced clearly. The dishonest 'fix' is stashing the missing credential somewhere the headless job can reach — which turns a one-time interruption into a permanent, invisible exposure.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.