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

No Elevated Escape Hatch

~11 min · no-escape-hatch, least-privilege, no-bypass

Level 0Lost in Finder
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"The most dangerous button a file manager can have is 'do it anyway, as root.' Waygate doesn't have it — and that absence is a feature."

The Temptation to Escalate

Sooner or later a file manager hits a wall: a folder it can't read, a file it can't delete, a permission macOS won't grant. The tempting fix is an escape hatch — prompt for the admin password, run the operation as root, install a privileged helper that can do anything, or shell out to a command that ignores the rules. Every one of those turns the app into a way to bypass the OS's own protections. Waygate refuses all of them.

What Waygate Categorically Does Not Have

No root. No privileged helper tool. No arbitrary shell execution, no AppleScript bridge, no plugin system that could run third-party code, no downloaded-code execution. Waygate runs as the user's normal account with the user's normal permissions, and that is the ceiling. There is no code path anywhere in the app that elevates beyond what the logged-in user can already do. The absence of an escape hatch is not a missing feature; it is the boundary that makes an unsandboxed app safe to run.

Surface the Denial, Don't Bypass It

So what happens at that permission wall? Waygate surfaces the denial honestly: it tells you exactly which item was denied and why, and it continues only where the plan's policy permits. If you genuinely need access, you change the permission in macOS — the system's own privacy and ACL controls — and try again. Waygate never tries to get around a macOS privacy decision; it respects it and hands the choice back to you, the human with the actual authority.

Waygate has no elevated escape hatch — no root, no helper, no arbitrary shell/AppleScript/plugin/downloaded code — and surfaces privacy/ACL denials instead of bypassing them. The app's ceiling is the user's own permissions. An operation blocked by macOS is reported, not escalated around; access changes happen in the system's controls, by the user.
Track cleared — the network and its secrets are handled. A saved endpoint is an address not a mount, credentials live only in Keychain, the unsandboxing is deliberate and compensated, and there is no escape hatch. Notice the through-line with the whole quest: Waygate earns trust by refusing power it doesn't need — no shadow catalog, no fake undo, no plugin OS, no root. Least privilege is the same instinct as least surface. Last track: what happens when something goes wrong anyway.

Code

Surface the denial; never escalate around it·swift
func perform(_ plan: OperationPlan) async throws {
    do {
        try await engine.execute(plan)
    } catch let error as POSIXError where error.code == .EACCES || error.code == .EPERM {
        // Permission denied by macOS. Waygate does NOT:
        //   - prompt for an admin password and re-run as root
        //   - install a privileged helper to force it
        //   - shell out to `sudo rm` to ignore the ACL
        // Waygate DOES: surface exactly what was denied, and stop.
        await surfaceDenial(item: plan.deniedItem, reason: error,
                            hint: "Change access in System Settings > Privacy, then retry.")
    }
}
// The user -- who has the real authority -- adjusts permission in macOS.
// The app respects the system's decision instead of tunneling under it.

External links

Exercise

Think of an app that asked for your admin password to do something with files, or installed a background helper. What could it do afterward that it couldn't before, and what would a bug in that elevated component put at risk? Then argue why 'surface the denial and let the user change the permission' is safer for the same real-world tasks.
Hint
An app that gained root (or installed a root helper) can now touch anything on the system, and a vulnerability in that path escalates to full compromise — a permanent liability for as long as it's installed. 'Surface the denial' keeps the app at the user's own privilege level: the worst a bug can do is what the user could already do. The user changing a permission in System Settings accomplishes the same task without ever handing the app powers it can be exploited to abuse.

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.