The STC's resting identity is STC/STCGROUP, which holds ALTER on every data set — log on to a low-privilege userid at startup

[mgrossmann]

Measured on mvsdev, 2026-08-12, while investigating the identity questions behind #64. Same finding and same fix as mvslovers/httpd#177; filed here because it applies to this STC independently.

The finding

Every started task on an MVS 3.8j system running RAKF gets the same hardcoded identity, and on a system with the usual profile that identity is close to omnipotent.

RAKF0010I STC FTPD     STARTED USING DEFAULT STC ACCOUNT
RAKF0010I STC HTTPD    STARTED USING DEFAULT STC ACCOUNT

That message comes from WTOSTC in SRCLIB/ICHSFR00.hlasm, commented "Report when hardcoded STC account is used". The path reaching it does no lookup:

RACINOID CLC   =F'0',X'C'(R8)      STC ?          <- is a proc name present?
         BNE   RACISSTC
RACISSTC LA    R4,STCUID-L'CBLKNEXT POINT TO UID  <- one hardcoded answer
STCUID   DC    AL4(0),X'03',CL8'STC',X'08',C'STCGROUP'

RAKF has no started-procedures table: the procedure name decides that the caller is an STC, never which one. Combined with

DATASET *          STCGROUP  ALTER

FTPD's resting identity holds ALTER on every data set on the system.

Adding USER= to the PROC does not change this — the FTPD PROC is a plain EXEC PGM=FTPD today, but even with it, that RACINIT path consults nothing.

Why this could not be seen from outside the address space

Worth recording, because the obvious check is wrong. ASXBSENV lives in the ASXB, which is in each address space's private area — FTPD's and HTTPD's ASXB pointers are both 009DF300. Reading FTPD's through another address space's debugger returns that address space's own ACEE and looks entirely plausible. The RAKF0010I message at STC start is the reliable answer.

Why per-session logins do not mask it

racf_login() returns the new ACEE through the ACEE= pointer in the parameter list and "never reads or writes ASXBSENV" (libc370/src/racf/raclogin.c:47-51 — the no-ENQ change from #64). So an FTP session logging on does not disturb the resting identity: it stays STC/STCGROUP for the life of the address space, and anything that runs without an explicit ACEE falls back to it.

That is the same fallback #64 is about. This issue is the other half: #64 asks which identity a check should use; this asks what identity is there when nobody sets one.

Proposal

At startup, once APF authorization is in place and before accepting connections, log on to a configured low-privilege userid and install it:

ACEE *stc = racf_login(cfg_stc_user, NULL, cfg_stc_group, &rc);
if (stc) racf_set_acee(stc);

pass == NULL bypasses password checking (racf.h:24-25), so no password goes into a config file.

To settle:

• Entitlements the userid actually needs — whatever FTPD opens before a client identity exists (its Parmlib member, logs). Enumerate, then grant exactly that. Everything a session touches must already go through the session's own ACEE; if anything does not, that is a finding in its own right and belongs with FTPD: cross-session ACEE race — OPEN-path racf_set_acee() switch is unserialized (ASXBSENV is address-space-wide) #64.
• Config keywords, defaulting to today's behaviour so an unconfigured system is unchanged.
• Failure policy — refuse to start, or continue on the inherited identity and log loudly.

Related

• FTPD: cross-session ACEE race — OPEN-path racf_set_acee() switch is unserialized (ASXBSENV is address-space-wide) #64 — the OPEN-path ACEE switch; this narrows what a mistake there can reach
• The STC's resting identity is STC/STCGROUP, which holds ALTER on every data set — log on to a low-privilege userid at startup httpd#177 — identical finding for HTTPD
• No per-task identity: RACHECK/RACDEF resolve the ACEE only from the plist or ASXBSENV MVS-sysgen/RAKF#5 — no per-task identity, the root of both
• A started-procedures table for RAKF is the proper upstream fix and is being drafted for a PR; this mitigation should not wait for it

[mgrossmann]

Two measurements from writing the RAKF setup guide (d2924fa) that bear on this issue.

The proposed mitigation is already in the code, with literals instead of keywords

src/ftpd.c:196-217 already does what the Proposal describes — logs on at startup and installs the ACEE:

new_acee = racf_login("FTPD", NULL, "USER", &racf_rc);
if (new_acee) {
    racf_set_acee(new_acee);
    ftpd_log_wto("FTPD004I STC IDENTITY SET TO FTPD/USER VIA RACINIT");

Measured on a TK5 system, 2026-08-14:

FTPD004I STC identity set to FTPD/USER via RACINIT

So the resting identity after startup is FTPD/USER, not STC/STCGROUP. What is left of this issue is therefore the three "To settle" bullets rather than the switch itself — above all the config keywords, since "FTPD" and "USER" are hardcoded at line 209 and cannot be changed without a rebuild.

RAKF0010I does not show the resting identity

Worth re-checking the evidence in the issue body. RAKF0010I STC FTPD STARTED USING DEFAULT STC ACCOUNT is issued by RAKF when the started task is created — before FTPD's own code runs, so before the RACINIT above. Seeing it says the initial assignment was STC/STCGROUP; it does not say the address space still holds that identity once FTPD has initialized.

The reliable indicator is FTPD's own FTPD004I against FTPD004W. If mvsdev showed FTPD004W, the switch was failing there — most likely because the FTPD user was missing from SYS1.SECURE.CNTL(USERS) — and that is a configuration finding rather than a missing feature.

RAKF does not check the group connection at RACINIT

Measured on the same system. With the users table carrying

FTPD     FTPD              N

and the code requesting group USER, the resulting ACEE was FTPD/USER — the group asked for wins, and no connection check refuses it. Two consequences for the keyword work here:

• A cfg_stc_group that names a group the userid is not connected to will be accepted silently, so the config cannot be validated by RAKF on our behalf.
• The users-table entry should still name the same group, or the table and the console disagree about what the server runs as.

One more thing that belongs with the entitlements bullet: RAKF 1.2.x rejects a blank password in the users table, so the low-privilege userid necessarily carries a real password and is a login-able account over FTP. It must not be permitted on FTPAUTH. The guide covers this; the failure policy bullet should account for it too.