dc
205d042bbe
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.
3.1 KiB
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
makedatadeletes 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.