Modules must stop switching ambient identity: ASXBSENV is address-space-wide and 3.8j has no per-task ACEE

[mgrossmann]

Rewritten 2026-08-11. The first version proposed bracketing the ACEE inside httppcgi() around the LINK. That fix is wrong — or rather, insufficient in a way that matters. It closes the abend case and leaves the structural problem standing, and it would have sent the next reader down the same dead end. The corrected analysis is below; see also mvslovers/ftpd#64, which reached part of this earlier.

Surfaced while validating mvsmf#223 against the new storage reclaim. #154/#174 made a CGI abend survivable — the storage is released and the server keeps running. That is what made this visible: leftover ambient state used to be moot because the server was dead anyway.

The structural fact

racf_set_acee() does not set a task field. It writes ASXBSENV (ASXB+0xC8, libc370/src/racf/racsacee.c:15) — address-space scope. libc370 says so (racauth.c:116):

ASXBSENV is address-space-wide: writing the ACEE there and back is visible to every other TCB in the address space for the length of the call

And on MVS 3.8j there is no per-task alternative — the TCB has no ACEE anchor, and libc370 accordingly never references one (grep: zero hits repo-wide). This is the point that changes the conclusion: per-request identity is not merely unbracketed, it is being kept in the only field available, and that field belongs to the whole address space. There is nowhere better to put it.

Meanwhile httpd runs one TCB per session (ATTACH EP=CTHREAD), default MINTASK=3 (httpprm.c:200).

So: a save/restore of a shared field cannot be made correct by moving who performs it. Any fix that keeps switching is serialization under another name.

Two concrete defects that follow

1. Abend leaves the identity behind. mvsMF sets it in identity_middleware (mvsmf/src/mvsmf.c:51) and restores at quit: (:151). httppcgi() brackets the storage (reclaim(HTTP_CGI_SUBPOOL) at :72, unconditional since #174) but never touches the ACEE — zero hits for acee in src/httppcgi.c. Abend between the two lines and the client's ACEE stays in ASXBSENV, address-space-wide, indefinitely. The comment at httppcgi.c:55 already names the precondition: "nothing runs its @@ExitA, the worker TCB survives by design".

2. Interleaving between concurrent workers.

worker 1:  old1 = set(A)      ASXBSENV = A
worker 2:  old2 = set(B)      ASXBSENV = B,  old2 = A
worker 1:  set(old1)          ASXBSENV = old1   <-- request B still running
worker 2:  set(old2)          ASXBSENV = A      <-- a finished request's identity, left behind

Who is exposed, and how badly

racf_auth() serializes its own set/RACHECK/restore under lock(asxb) (libc370/src/racf/racauth.c:68,120,135,148), so any authorization decision made through it is race-free regardless of the above. That is the dividing line:

Consumer	Pattern	Consequence
httpd	passes httpc->cred->acee explicitly (httpxauth.c:143)	safe
ftpd	explicit racf_auth() pre-check + an unserialized switch on the OPEN path	entitlement safe, spurious OPEN failures — ftpd#64
mvsmf	no racf_auth() call anywhere; plain fopen(dsname,"r") (dsapi.c:916)	the ambient value is the authorization
httprexx / httplua	never touch an ACEE (grep: 0 files each)	inherit whatever is in ASXBSENV

ftpd#64 asked for exactly this enumeration — "any fopen not preceded by a racf_auth pre-check would rely on the racy OPEN check directly — higher concern; enumerate such sites". mvsMF is that site, across the whole dataset API. Nobody had gone through it.

The API for the right fix already exists, with zero consumers

httpxauth.c:137 already exports, through the HTTPX vector:

int http_check_auth(HTTPC *httpc, const char *classname,
                    const char *resource, int attr);

It calls racf_auth(httpc->cred->acee, ...) — ACEE in the parameter list, no ambient dependency, self-serializing — and normalizes SAF rc 4 to 0 so the published contract holds (0 permitted, 8+ refused, -1 unauthenticated). Its own comment notes: "no CGI calls http_check_auth()".

So the export landed and nothing adopted it; modules kept switching identity instead.

Proposed direction

Not "httpd performs the switch instead of the module" — that was the first draft and it leaves the shared field shared. Rather:

No module touches an ACEE. httpd answers "may this client access resource X with attribute Y."

With that, this issue does not get fixed so much as it becomes moot: nobody can leave an identity behind, because nobody sets one.

The trade-off, stated plainly, because it is a real one. Today the gate is implicit and universal — every fopen() goes through RACHECK, including the ones nobody thought about, just under an identity drawn from a shared field. Afterwards the gate is explicit and correct, but only where it was written. If a module opens under the server's identity, a forgotten http_check_auth() is not a weak gate, it is no gate. Whether to keep the ambient switch as a second, implicit net — accepting everything above as the price — is the decision this issue needs before code moves.

Work implied

• mvsmf: adopt the pre-check model, drop the racf_set_acee() pair. Its own ticket; the largest of the three and the only one carrying real security weight. The fopen sites in dsapi.c are the work list.
• ftpd#64: its "VERIFY FIRST — does OPEN consult TCBSENV" is answered, negatively. Noted there.
• first consumer of http_check_auth(): per its comment, that is also the moment to verify the dbgf() path under DEBUG 1, which has never run from a CGI.

Scope of the evidence

Code reading, plus a live check of which build is running (/.dsrv?target=MOD shows no route->reclaim row, so the stand is post-#175). Neither the abend leftover nor the interleaving has been reproduced on a live system — that means deliberately abending a CGI, which is worth arranging rather than doing in passing.

[mgrossmann]

Sequencing decided on the mvsMF side, recorded here because it determines how this issue resolves.

mvslovers/mvsmf#228 takes the half that is right under every future: introduce explicit http_check_auth() authorization before each dataset operation. It deliberately does not remove the ambient switch.

The reason that split matters for this issue: racf_auth() serializes its own set/RACHECK/restore under lock(asxb) (libc370/src/racf/racauth.c:68,120,135,148). So once the authoritative decision moves into http_check_auth(), the defects above stop being entitlement problems for mvsMF and become hygiene — the same reasoning ftpd#64 uses for its own severity. They do not go away, and for httprexx/httplua (which never touch an ACEE) nothing changes at all.

So this issue keeps its full weight, with two candidate resolutions:

1. A per-task ACEE — a convention between RAKF and libc370 on a TCB word free on 3.8j, consulted ahead of ASXBSENV. Preferred: it fixes the class rather than routing around it, and it keeps the implicit gate and makes it correct. Note this is not a RAKF feature toggle — the TCB layout is MVS's, so it is a two-project control-block agreement, and RAKF is not in this org.
2. Remove the switch entirely — modules never set an ACEE, opens run under the server identity, this issue becomes moot. Fallback if (1) does not land.

(2) is deliberately not being done now: it trades an implicit universal gate for one that exists only where written, and it is exactly what (1) would render unnecessary.

Also worth flagging as unverified, since it is load-bearing for both this issue and #228: whether OPEN on 3.8j performs the RACF check itself or RAKF hooks in elsewhere. The "implicit universal gate" framing comes from ftpd#64's wording, not from a measurement. It does not change the work in #228, but it changes how much net option (2) would actually remove — and it should be settled before a per-task-ACEE request is written, since it determines where such a field would have to be consulted.

[mgrossmann]

Measured on mvsdev today. Two things this settles, one of which raises this issue's priority substantially.

1. The implicit gate is real — RAKF enforces inside OPEN

Previously taken from ftpd#64's wording and flagged here as unverified. Now measured, with an ordinary (non-admin) userid against a data set the RAKF profile denies it (SYS1.SECURE.*: UACC NONE, ADMIN NONE, RAKFADM UPDATE):

control   MVSCE02 GET /zosmf/restfiles/ds/SYS1.PARMLIB(IEASYS00)     -> 200, content
test      MVSCE02 GET /zosmf/restfiles/ds/SYS1.SECURE.CNTL(PROFILES) -> blocked, no content

Console at that moment:

RAKF0005 INVALID ATTEMPT TO ACCESS RESOURCE
RAKF000A  MVSCE02

RAKF logs denials only — a successful open produces no message at all, which is why an earlier read of the same data set under a permitted id looked like "no check happened". So the "every fopen() goes through a check" framing in this issue, #228 and ftpd#64 is confirmed.

2. Every denied access is a CGI abend — so this issue's failure mode is routine, not rare

The enforcement mechanism is not a return code:

IEC150I 913-38
MVSMF99E Handler abend S913 U0000 for GET /zosmf/restfiles/ds/SYS1.SECURE.CNTL(PROFILES)

S913 — insufficient authority — is an ABEND. OPEN does not fail politely; it terminates the task, and mvsMF's ESTAE turns that into 500 {"rc":8,"category":6,"reason":99,"message":"Internal server error (abend recovery)"}.

That closes a gap in the analysis above. This issue describes the ACEE being left in ASXBSENV "when a CGI abends between the two lines", which reads like an edge case. It is not:

A CGI abend is the normal outcome of a denied access. So every authorization failure leaves the requesting client's ACEE in ASXBSENV, address-space-wide.

The exposure is no longer "if something goes wrong". It is: any user who requests something they are not permitted to — a typo, a Zowe client walking a data set list, a scan — leaves their identity pinned in the address space for whatever runs next. For httprexx/httplua, which never touch an ACEE, that is the identity they then run under.

Also observed on an ordinary error path: IEC143I 213-04 / MVSMF99E Handler abend S213 for a data set that cannot be opened at all (SYS1.STGINDEX). So abends are not confined to denials either.

The server itself stayed healthy across all of them — conns(0) creds(1) workers(3) busy(0) flat before and after, no HTTPD906W. #154/#174 doing its job, and precisely why this is now reachable rather than academic.

What that changes

Nothing about the direction, everything about the urgency. The bracket-vs-per-task-ACEE question is unchanged, but "leftover identity" moves from a rare abend window to the routine consequence of a permission check saying no.

Worth noting the interaction with mvsmf#228: an explicit http_check_auth() pre-check refuses before the open, so it returns a clean 403 and never reaches the S913. That removes the abend on the denial path entirely — i.e. #228 does not merely make the identity question hygienic for mvsMF, it also stops generating the abends that trigger this issue in the first place.

[mgrossmann]

Two details from the full console record, both sharpening this issue.

RAKF000A  MVSCE02 ,HTTPD   ,DATASET ,SYS1.SECURE.CNTL
IEC150I 913-38,IFG0194C,HTTPD,HTTPD,SYS00035,151,MVS000,SYS1.SECURE.CNTL

1. Attribution is correct — it is only the lifetime that is broken. RAKF logged the check against MVSCE02, the requesting client, not against HTTPD or the admin id the session was otherwise using. So identity_middleware's switch does put the right ACEE in place for the request it belongs to. This issue is not about the wrong identity being checked; it is about that identity outliving the request and being visible to the whole address space. Worth stating explicitly so nobody reads the concurrency scenario above as "mvsMF authorizes as the wrong user today".

2. The enforcement point is stock OPEN processing. The abend is issued by IFG0194C, an IBM OPEN executor. It is not a member of SYS1.LPALIB (which has IFG0194A/IFG0194J), nor of SYS1.SVCLIB (59 members, no IFG* at all), so it is a CSECT inside a linked OPEN module — IEC150I names the issuing CSECT, not the load module. RAKF is not replacing OPEN; it supplies the decision behind the check OPEN already makes.

That matters mainly for the per-task-ACEE option sketched above: such a field would have to be consulted by whatever RAKF implements behind that call, which is RAKF's own code rather than an MVS modification. Feasible in principle, but confirming how RAKF plugs in needs its modules or source, which are not on this stand — SYS1.SECURE.CNTL holds only the profile and user data.

[mgrossmann]

Measured what actually rests in ASXBSENV between requests. It corrects one of my own claims above and reframes where the exposure sits.

Walked live on the running HTTPD address space via /.dm:

PSA+0x224 (PSAAOLD)   -> ASCB 00FD0718
ASCB+0x6C (ASCBASXB)  -> ASXB 009DF300
ASXB+0xC8 (ASXBSENV)  -> ACEE 009DCA30      <- non-zero

ACEE 009DCA30:
  +00  C1C3C5C5                    "ACEE"
  +15  03 E2E3C3 4040...           ACEEUSRL=3, ACEEUSRI="STC"
  +1E  08 E2E3C3C7D9D6E4D7         ACEEGRPL=8, ACEEGRPI="STCGROUP"

So the resting identity is userid STC, group STCGROUP — the started task's own, installed by RACINIT at STC start and restored by mvsMF's racf_set_acee(session.old_acee) at quit:.

Correction to my earlier comment

I wrote that a leftover ACEE could fail open — "if an admin user's ACEE is left behind, the implicit OPEN check grants more, not less". On this stand that is wrong, and backwards. The RAKF profile is:

DATASET *                    READ
DATASET *          ADMIN     ALTER
DATASET *          STCGROUP  ALTER

STCGROUP already holds ALTER on every data set. The resting identity is therefore the most privileged one in play, and a client ACEE left behind by an abend is a downgrade, not an escalation. That does not make the abend leftover harmless — an identity outliving its request is still wrong, and the concurrency interleaving is unaffected — but the "fails open upward" argument does not hold here and I withdraw it.

Where the exposure actually is

Not in the leftover. In the resting state itself: any CGI that does not establish its own ACEE runs as STC/STCGROUP, i.e. with ALTER on every data set on the system. That is the normal condition between requests, not an error path.

httprexx and httplua are exactly that shape — neither references racf_set_acee nor http_get_acee (grep: zero files each). Deploy either alongside mvsMF and it inherits ALTER on everything.

Scope on this stand today: latent, not live. The registered modules are

HTTPD036I Module MVSMF    registered for /zosmf/info, /zosmf/services/authenticate, /zosmf/*
HTTPD036I Module HTTPDSRV registered for /.dsrv
HTTPD036I Module HTTPDM   registered for /.dm
HTTPD036I Module HTTPDMTT registered for /.dmtt

mvsMF sets its own ACEE per request; the three display modules read storage, not data sets. So nothing currently does data set I/O under the resting identity. It becomes live the moment an ACEE-unaware CGI that touches data sets is registered.

What that implies for this issue

It strengthens the direction rather than changing it. If httpd owns the identity — establishing it around the LINK and, better, if no module ever switches it (mvslovers/mvsmf#228) — then "what a CGI inherits when it does nothing" stops being STC/STCGROUP and starts being a deliberate choice. Worth stating in whatever lands here: the default a CGI runs under is a security decision, and today it is the most privileged identity in the address space.

Also worth noting for anyone reading the profile: MVS-sysgen/RAKF's own history flags this family of userid — commit 8904e07, "STC and PROD were hardcoded in to RAKF with the default password GREATONE … STC runs with systems OPERATION, bypassing all security." Check that your stand carries that fix.

[mgrossmann]

The #177 displacement now attributes here — plus a derived fail-open chain the reaper completes

Two additions, one measured from source, one derived from source and not yet
reproduced. Both raise this issue's weight; neither changes its direction.

1. The leftover this issue predicts has, in all likelihood, been observed live

#177 measured the resting identity being displaced by a client's
(IBMUSER/ADMIN in ASXBSENV between requests) and proposed RAKF's
RACINIT ENVIR=CREATE planting it there as the leading explanation. The RAKF
source refutes that for our logins: the CREATE path stores to ASXBSENV only
when the caller supplies no ACEE= pointer (ICHSFR00.hlasm:557-564 — non-zero
ACEE= word at +x'34' returns the ACEE through the pointer instead), and
libc370's racf_login() always passes one (raclogin.c:125-126, full 0x38
plist). Details on #177.

That eliminates the last writer outside our own brackets. racf_set_acee() is
called in exactly one place (the startup switch); the display modules never touch
an ACEE. What remains is precisely this issue's mechanism: mvsMF's per-request
set/restore (interleaving between workers, or the abend path) and the
racf_auth() window. Not proven — the server's full request history at the time
of the reading wasn't recorded — but there is no remaining innocent explanation
for a client identity at rest.

2. The chain does not stop at "wrong identity resting" — the reaper drives it to fail-open

Derived from source; each link is individually verified, the chain end-to-end is
not. Recording it because it turns the leftover from "wrong identity" into "no
identity", which RAKF treats as permitted:

1. A denied access abends the CGI (S913, routine per the measurement above), and
   the client's ACEE stays in ASXBSENV — this issue's defect 1.
2. The client goes idle. After SESSION_TIMEOUT the reaper frees the CRED and
   its ACEE: httpd.c:607 → cred_reap() → credfree.c:33 racf_logout().
3. racf_logout() clears ASXBSENV by hand when it still points at the ACEE just
   deleted (raclgout.c:68-74 — measured there; RAKF itself leaves the dead
   pointer). Necessary — resting on freed storage would be worse — but the field
   is now zero.
4. RAKF's RACHECK path treats that as allow (ICHSFR00.hlasm:111-116): no plist
   ACEE, ASXBSENV zero → BZ RACHGOOD, comment "WHO KNOWS".

So: denial → abend → idle timeout → every ACEE-less authorization in the
address space passes, until the next request happens to rest a new identity.
ftpd met exactly this class and fixed it in #78 by always restoring the STC ACEE;
httpd has no equivalent restore point, because no httpd code performed the switch
that left the identity behind.

A live check would be cheap and is worth doing once: provoke a denial abend as an
ordinary user, wait out SESSION_TIMEOUT, read ASXBSENV via /.dm
(PSA+0x224 → ASCB+0x6C → ASXB+0xC8) and expect zero.

What this changes

Nothing about the resolution options — per-task ACEE preferred, switch removal as
fallback. But it sharpens the interim priority: mvslovers/mvsmf#228 cuts this
chain at link 1 (an explicit http_check_auth() refusal answers 403 and never
reaches the S913), which makes it the one step that reduces this issue's live
exposure without waiting on any RAKF work. #177's low-privilege resting identity
helps only while it actually rests; once displaced, it doesn't.