Normalize portable sudo skill #17

New issue

Open

opened 2026-08-22 06:49:24 +00:00 by lost-rob0t · 1 comment

lost-rob0t commented

2026-08-22 06:49:24 +00:00

(Migrated from github.com)

Parent: #13

Goal

Recover the prior sudo skill as a portable privilege/authorization contract without hard-coding one workstation's desktop portal, polkit flow, username, or command path.

This issue is design/spec only until a later RAGE implementation slice consumes it.

Intended scope

The skill should help an agent:

recognize when an operation actually requires elevated privilege;
prefer the user's existing authorization mechanism;
surface the exact privileged command/action for approval rather than broadening authority;
keep privilege escalation narrow and temporary;
verify the requested operation after authorization;
avoid turning an interactive desktop/polkit implementation detail into a universal dependency.

Format gate

Canonical package:

skills/sudo/SKILL.md

Frontmatter:

---
name: sudo
description: sudo, privilege, authorization, escalation, polkit
compatibility: <only if a concrete capability is truly required>
---

Keep the body concise and capability-oriented. Put implementation-specific examples in references only if they are genuinely useful.

Portability

Describe the semantic dependency as an authorization capability, not as lost-rob0t/dotfiles, a particular portal, or a particular desktop environment.

An owner-specific fast path may be retained only under an explicit compatibility section. Other users must be allowed to use sudo, doas, polkit, a desktop authorization broker, or another already-configured mechanism as appropriate to their environment.

Safety/authority invariants

do not infer standing root authorization from one approved action;
do not cache or expose credentials;
do not rewrite sudoers/polkit policy unless that policy change is itself the requested task;
prefer the narrowest privileged action;
preserve the surrounding agent/runtime permission model;
do not use privilege escalation to bypass a denied tool or policy boundary.

Acceptance

clear semantic boundary around privilege acquisition/use;
no machine-specific implementation is universalized;
keyword-only canonical description;
dependencies are explicit but minimal;
implementation can later be validated on environments with different privilege mechanisms.

Parent: #13 ## Goal Recover the prior `sudo` skill as a portable privilege/authorization contract without hard-coding one workstation's desktop portal, polkit flow, username, or command path. This issue is design/spec only until a later RAGE implementation slice consumes it. ## Intended scope The skill should help an agent: - recognize when an operation actually requires elevated privilege; - prefer the user's existing authorization mechanism; - surface the exact privileged command/action for approval rather than broadening authority; - keep privilege escalation narrow and temporary; - verify the requested operation after authorization; - avoid turning an interactive desktop/polkit implementation detail into a universal dependency. ## Format gate Canonical package: ```text skills/sudo/SKILL.md ``` Frontmatter: ```yaml --- name: sudo description: sudo, privilege, authorization, escalation, polkit compatibility: <only if a concrete capability is truly required> --- ``` Keep the body concise and capability-oriented. Put implementation-specific examples in references only if they are genuinely useful. ## Portability Describe the semantic dependency as an authorization capability, not as `lost-rob0t/dotfiles`, a particular portal, or a particular desktop environment. An owner-specific fast path may be retained only under an explicit compatibility section. Other users must be allowed to use sudo, doas, polkit, a desktop authorization broker, or another already-configured mechanism as appropriate to their environment. ## Safety/authority invariants - do not infer standing root authorization from one approved action; - do not cache or expose credentials; - do not rewrite sudoers/polkit policy unless that policy change is itself the requested task; - prefer the narrowest privileged action; - preserve the surrounding agent/runtime permission model; - do not use privilege escalation to bypass a denied tool or policy boundary. ## Acceptance - clear semantic boundary around privilege acquisition/use; - no machine-specific implementation is universalized; - keyword-only canonical description; - dependencies are explicit but minimal; - implementation can later be validated on environments with different privilege mechanisms.

nsaspy commented

2026-09-08 01:33:53 +00:00

Owner

Modeling sudo as a portable privilege contract rather than a bound desktop portal is the right instinct. The key is to separate the authorization decision from the transport: define the contract in terms of (command, args, target identity, scope, approval reference) so it can be enforced by a polkit policy, a setuid wrapper, or a remote authority without re-writing the agent's call site. One tradeoff to plan for: if the authority is a separate process from the agent, you need an audit record that binds the approval to the resulting elevation, otherwise a reviewer cannot tell which logged-in user's privilege was used. That binding (approval id in the elevation event) is usually what breaks in these designs, more than the auth itself.