permissions: a plugin can mark part of its surface owner-only
A plugin worth granting to a Member can also hold the credential the rest of it runs on. Jellyfin's /_config stores a server's admin token and drives account provisioning; the rest of the plugin is exactly what a Member should have. The choice was all of it or none of it. `ownerOnly` on a plugin permission takes sub-paths relative to the mount prefix. The permission stays fully grantable — this is not the ownerOnly PERMISSION that manifest.ts refuses, and that refusal still stands: a permission nobody can delegate is a contradiction. This says a few paths administer the plugin rather than use it. Declared by the plugin, enforced by the platform. A plugin could check this itself and the first one would; the tenth would add a route and forget, with no boot failure and no warning — the shape assertPermissionTotality exists to prevent. In the gate it is enforced once, on the door they all pass through, and a route added later by someone who never read the manifest is covered by default. Checked before selfService and before kind. A path that is somehow both self-service and owner-only is a contradiction, and the safe reading has to win. A write grant does not unlock it either — level is not the question this answers. Also forwards X-Officer-Owner and X-Officer-Level to a sidecar whose proxy names its permission key, for the finer decisions the platform cannot make for it: whose rows a read returns, which fields a level may see. Facts, never the role name — a plugin branching on "Super Admin" would give every plugin repository an opinion about the platform's role vocabulary, and renaming a role would change authorization in code the platform does not own. These are safe to trust only because the proxy copies a three-item allowlist off the inbound request; that is now written where it would be changed. The owner's level is reported as write rather than the absent 'none': they hold everything implicitly and appear in no grants map, so the raw lookup inverts the meaning for the one account that can do anything. No plugin declares one yet. Jellyfin cannot until connections stop being per-user — locking /_config today leaves a Member with a plugin that only shows a connect form they may not submit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -6,6 +6,7 @@ import {
|
||||
permissionForApiPath,
|
||||
permissionForWsProvider,
|
||||
isRequestAllowedAtLevel,
|
||||
isOwnerOnlyRoute,
|
||||
isSelfServiceRoute,
|
||||
type PermissionLevel,
|
||||
} from './registry';
|
||||
@@ -131,6 +132,13 @@ export async function isApiRequestAllowed(
|
||||
// a 403 on a route that does not exist is not a leak, and a permissive default here would be.
|
||||
if (!permission) return { allowed: false, reason: 'no permission covers this path' };
|
||||
|
||||
// BEFORE self-service, and before kind. A permission can be fully granted and still have an
|
||||
// administrative corner — a plugin's settings, holding the credential the rest of it runs on. The owner
|
||||
// already returned above, so reaching here at all means this is not them.
|
||||
if (isOwnerOnlyRoute(permission, path)) {
|
||||
return { allowed: false, reason: `that part of ${permission.label} is restricted to the server owner` };
|
||||
}
|
||||
|
||||
// Checked before kind, because a self-service route acts on the caller and is therefore not the thing
|
||||
// the permission around it restricts. Exact method and path only — see the field's comment.
|
||||
if (isSelfServiceRoute(permission, method, path)) return { allowed: true };
|
||||
|
||||
Reference in New Issue
Block a user