docs(deploy): the window has no admin gate, and why

Replaces the risk-register framing with the assessment: there is no admin group
until makedata creates it, the caller is the administrator doing the deployment,
the configurator in the same window is more powerful than these two actions, and
a successful run deletes the service anyway.

Filed as deploy-window-authorization.md so the next review finds the reasoning
instead of re-raising the finding.
This commit is contained in:
dc committed 2026-11-03 11:59:24 +00:00
1 parent e84cfaaabd
commit 205d042bbe
2 files changed
+33 -35

No files matched your search

@@ -0,0 +1,33 @@
# Why the deploy window has no admin gate
The deploy screens ask two questions about the physical filesystem - what folders sit below this parent, and can the deployment user write to this one. Both are answered by `makedata` (`ACTION=DIRLIST` and `ACTION=WRITECHECK`), through `mpe_adminsetup.sas`.
Neither action checks a group, and this note records why that is the right answer rather than an oversight - so the next review does not have to work it out again.
## The window is the deployment itself
`makedata` exists from the moment the service pack is deployed until it runs successfully, at which point it deletes itself (and, on SASjs Server, the configurator). Deploying the pack and running `makedata` is an administrator's job, done in one sitting; there is no steady state in which these actions are reachable on a configured system.
What the actions do, for the record:
- `DIRLIST` - enumerate the folders below any absolute path the SAS process can open. Folder names only; no file contents, no file listing.
- `WRITECHECK` - ask whether a path exists, is a folder, and whether the deployment user can create and delete a file in it. It creates a uniquely named probe file and removes it again.
Both refuse a value carrying a macro trigger, a quote or a statement separator, and shape check it with `mp_validatecol(ISPATH)` before use.
## Why there is no group check
Every other admin service gates on `&mpeadmins`, which comes from `MPE_CONFIG` in the control library - and that library is what `makedata` creates. Before it runs there is no group to check: `%mpeinit()` reads `&DC_LIBREF..mpe_config` and has nothing to read. That is also why the previous `dirlist` service could never serve the deploy screen it was written for.
The window is not narrower than the configurator's own: on SASjs Server the configurator page, in the same window, lets the caller pick any group they belong to and create the control library - which is full Data Controller admin. `DIRLIST` and `WRITECHECK` are strictly less powerful than that.
## The assessment
- **There is no admin group to check.** It is created by `makedata`, from the group the deployer picks in the configurator.
- **The caller is the administrator.** Reaching these actions means reaching the STPs of a deployment in progress, which is the same caller the configurator is serving in the same window.
- **The actions are the weaker half of that window.** The configurator, in the same window, lets the caller pick any group they belong to and create the control library - which is full Data Controller admin. Listing folders and probing a write cannot achieve that.
- **They do not survive.** A successful `makedata` deletes the service, so a configured system has nothing that can enumerate a directory or write a probe file.
## If it ever stops being internal
The option, if these actions are ever reachable outside a deployment, is a gate that does not depend on the control library - an allowlist in the service, or an OS/metadata group named at deploy time. That is a change to how the deploy screens authenticate rather than a change to this service.
-35
View File
@@ -1,35 +0,0 @@
# The deploy window: who can browse the filesystem before Data Controller is configured
The deploy screens ask two questions about the physical filesystem - what folders sit below this parent, and can the deployment user write to this one. Both are answered by `makedata` (`ACTION=DIRLIST` and `ACTION=WRITECHECK`), through `mpe_adminsetup.sas`.
This note records the exposure that comes with that, so it is a decision rather than an oversight.
## The window
`makedata` exists from the moment the service pack is deployed until it runs successfully, at which point it deletes itself (and, on SASjs Server, the configurator). Those two actions are therefore reachable in that window by any caller who can reach the STPs at all.
What that caller can do:
- `DIRLIST` - enumerate the folders below any absolute path the SAS process can open. Folder names only; no file contents, no file listing.
- `WRITECHECK` - ask whether a path exists, is a folder, and whether the deployment user can create and delete a file in it. It creates a uniquely named probe file and removes it again.
Both refuse a value carrying a macro trigger, a quote or a statement separator, and shape check it with `mp_validatecol(ISPATH)` before use.
## Why there is no group check
Every other admin service gates on `&mpeadmins`, which comes from `MPE_CONFIG` in the control library - and that library is what `makedata` creates. Before it runs there is no group to check: `%mpeinit()` reads `&DC_LIBREF..mpe_config` and has nothing to read. That is also why the previous `dirlist` service could never serve the deploy screen it was written for.
The window is not narrower than the configurator's own: on SASjs Server the configurator page, in the same window, lets the caller pick any group they belong to and create the control library - which is full Data Controller admin. `DIRLIST` and `WRITECHECK` are strictly less powerful than that.
## What bounds it
`makedata` self-destructs after a successful run, so a configured deployment has no service that can enumerate a directory or write a probe file. The exposure exists only between deploying the pack and running `makedata`.
Two things follow for an operator:
- run `makedata` as part of the same session as the deploy rather than leaving a deployed but unconfigured pack in place;
- if a deployment is abandoned mid-flight, remove the service pack, which removes `makedata` with it.
## If it needs to be tighter
The remaining option is a deployment-time gate that does not depend on the control library - for example an allowlist of callers supplied in the service (or an OS/metadata group named before deployment). That is a change to how the deploy screens authenticate, not a change to this service, and it is deliberately not part of it.