[mgrossmann]

Summary

• setup_mvsce.py writes the four z/OSMF routes that mvsMF documents. The new one is MOD=MVSMF /zosmf/restconsoles/* AUTH=TOKEN RES=FACILITY:MVSMF.CONSOLE, placed before the /zosmf/* catch-all.
• The comment above HTTPPRM0 points at the mvsMF documentation and states that the first match wins.
• setup_rakf defines the profile FACILITY MVSMF.CONSOLE (RDEFINE, UACC NONE) and permits READ to IBMUSER only. RDEFINE and PERMIT run as separate IKJEFT01 steps.
• HTTPPRM0 sets RES_NOPROFILE=DENY, so a RES= route whose profile is missing is refused.
• RAKF pinned to the re-uploaded TK5INST.zip (sha256 34a3556a…); HTTPD raised from 4.3.0 to 4.5.1; README table updated.

Closes #40

Test plan

Done:

• Local image built with HTTPD 4.5.1 and RAKF 2.0.0 (docker build exit 0). RDEFCON job: RDEF and PERM both CC 00000; RAKFPROF7 RAKF PROFILES UPDATED seen.
• One container from the local image (MVSCE_TARGET_IMAGE=mvsce mvsce-target up --pull missing):
  • HTTPD 4.5.1 starts with the new HTTPPRM0. No HTTPD425W and no HTTPD426W in the log.
  • GET /zosmf/restconsoles/v1/log: without login 401; with IBMUSER basic auth 200.
• Container removed with mvsce-target down; mvsce-target list empty.

Not done:

• A logged-in user who is not permitted on FACILITY MVSMF.CONSOLE was not tested. Expected result: 403. No second test user with a known password was available.

Corrections

• The commit message of 26a8e03 says the console route needs the refusal. That was wrong for HTTPD 4.5.1 without the keyword. The keyword is now set in HTTPPRM0 (commit 4d116a7). The message of 26a8e03 is not rewritten because the branch is pushed; rewriting it would need a force-push.
• The first RDEFCON run failed with CC 8. Cause: a leading blank in front of RDEFINE makes RAKF 2.0.0 run the command as ADDSD, which creates a DATASET profile, and the following PERMIT then fails with "No universal access record found". The RAKF commands in this PR start in column 1 and RDEFINE and PERMIT are in separate steps.

[mgrossmann]

Review of 26a8e03 (head of #41).

Verified

• mvsce/setup_mvsce.py:142: the new route line is byte for byte the one in mvsMF docs/installation.md on main (line 212) and precedes /zosmf/*. Correct.
• mvsce/Dockerfile:89: I downloaded TK5INST.zip of the RAKF v2.0.0 release just now; its SHA-256 is 34a3556a…3ec6d, as pinned.
• CI is green on both architectures; the PR description records a local build with BUILD_EXIT=0 and a container test of the route.
• The finding in the PR description is right: mvsce/Dockerfile:80 pins mvsMF 1.3.0, and the console handler of 1.3.0 does not check FACILITY MVSMF.CONSOLE itself (that check arrived with mvsMF 1.4.0, see its CHANGELOG, #347/#460; git grep MVSMF.CONSOLE v1.3.0 -- src finds nothing). So with this PR the console route is still open to every logged-in user, exactly as /zosmf/* AUTH=TOKEN left it on main. The PR does not make anything worse, but the new RES= reads as a gate and is none, and every start of the image will log HTTPD425W ... NOT GATED.

Must fix

1. mvsce/setup_mvsce.py:904-905 (setup_rakf): define the profile in the same script that writes the route. The REXX already inserts FACILITYFTPAUTH; add FACILITYMVSMF.CONSOLE with universal NONE and READ for the group ADMIN, the same pattern as FTPAUTH (IBMUSER, which the setup verification uses against /zosmf/test, is in ADMIN). The merge loop sorts, so the new lines only need to be in ascending order among themselves. Failure scenario today: a user in group USER logs in and POST /zosmf/restconsoles/consoles/defcn runs an operator command. Sure.
2. mvsce/setup_mvsce.py:138-143: once the profile is defined, add RES_NOPROFILE=DENY to HTTPPRM0. setup_rakf runs and reloads RAKFPROF before HTTPD is started, so the start writes neither HTTPD425W nor HTTPD426W. This is what the HTTPD installation guide says for a new system whose profile definitions are part of the installation. Sure.
3. Commit message of 26a8e03: "The console route needs that refusal" and "a RES= route whose profile is missing is refused" describe a behaviour the image does not have (the keyword is not set). The PR description corrects it, but the commit message is what git log keeps. Reword the commit before the merge (a force-push on this branch is fine). Sure.

Suggestion

• Step 5 of the setup verification (module docstring, lines 56-63) could fail the build on HTTPD425W/HTTPD426W in the HTTPD start log, so a profile that is lost again is caught at build time instead of in the container.
• Moving mvsMF to 1.4.1 would make the console fail-closed in the handler itself, but that also needs the JESSPOOL profiles of 1.4.0 and is a change of its own; see the follow-up issue.

Who gets READ on the profile (group ADMIN only, as proposed above) is still an open decision on our side; I will state it here as soon as it is taken.

CHANGES REQUESTED

[mgrossmann]

Review of 4d116a7 (head of #41), after the first review on 26a8e03.

Verified

• mvsce/setup_mvsce.py:934-950: RDEFCON defines FACILITY MVSMF.CONSOLE with UACC(NONE) and permits READ to IBMUSER only, as decided. Both steps are listed in run_job, which fails the build unless each step appears with CC 00000 (run_job, line 296), so a failed RDEFINE or PERMIT cannot slip through. The job runs before S RAKFPROF and before HTTPD is started.
• mvsce/setup_mvsce.py:142: RES_NOPROFILE=DENY is in HTTPPRM0; with the profile loaded first this is the order the HTTPD installation guide prescribes for a new system.
• The container test in the PR description matches what was required: no HTTPD425W/HTTPD426W at the start, 401 without a login, 200 for IBMUSER on /zosmf/restconsoles/v1/log, container down and list empty.
• The three must-fix points of the first review are addressed. On the third: the message of 26a8e03 stays as it is. 4d116a7 explains the actual behaviour and the keyword it sets, and the PR is merged with a merge commit, so the history shows both. No force-push needed.
• Not tested: a logged-in user without READ gets 403. Acceptable here, the gate is HTTPD's own RES= path, which HTTPD's tests cover; the image has no second user with a known password.

Suggestion

• mvsce/setup_mvsce.py:940 and :947: the RAKF commands must start in column 1 (a leading blank makes RAKF 2.0.0 run ADDSD and define a DATASET profile; the PERMIT then fails). That is in the PR description but not in the file. A one-line comment above the JCL would save the next editor the same CC 8.

Merge once CI is green on 4d116a7.

APPROVE