dc/.agents/docs/deploy-window-authorization.md

What guards the deploy window

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_dirlist.sas and mpe_writecheck.sas.

This note records the two-layer answer: a gate that closes the window once the appLoc is configured, and why the window itself has no group check.

The gate

The deploy window is over once the appLoc has services/public/settings.sas: makedata writes it at the end of a successful run, and a run that failed - or was abandoned - after writing it leaves the file behind. So the service refuses DIRLIST and WRITECHECK whenever that file is present, however the run that created it ended. On SASjs Server the file is fetched with ms_getfile and a probe that cannot answer (anything other than 200 or 404) is treated as configured: an unreachable drive is not evidence that the window is open. Viya checks the same file through mfv_existfile.

The consequence for tests: the browse actions are refused on any appLoc that runs the suite, because every such appLoc is configured. services/admin/makedata.test.sas therefore asserts the refusal, and the listing and write-probe behaviour is asserted against the macros directly (macros/mpe_dirlist.test.sas, macros/mpe_writecheck.test.sas). The macros' own abort paths (a relative path, one carrying a macro trigger) are not asserted anywhere: mp_abort cannot be exercised inside the test session.

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 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. The shape check fails closed: an absent ISPATH rule refuses the path rather than accepting it.

The assessment

• The window is the deployment itself. makedata is deployed, run once by an administrator, and deletes itself on success.
• There is no admin group to check while it runs. 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.
• The window closes on the settings file, not on survival of the service. That is what covers a failed or abandoned run.