FTPD: cross-session ACEE race — OPEN-path racf_set_acee() switch is unserialized (ASXBSENV is address-space-wide)

[mgrossmann]

Summary

The per-session identity switch used around dataset OPEN
(racf_set_acee(sess->acee) … fopen … racf_set_acee(oldacee) in
ftpd#mvs.c) writes the address-space-wide ASXBSENV field, while FTP
sessions run as concurrent subtasks (separate TCBs) in one address space.
The OPEN-path switch is not serialized, so a concurrent worker's ASXBSENV
write can bleed into an in-flight OPEN's internal RACF check.

This is a pre-existing latent bug, independent of the ABEND-recovery work in the
linked PR (that PR only re-establishes the same field's normal resting value and
does not change the steady-state switch).

Evidence

• libc370/src/racf/racsacee.c:34,53 — racf_set_acee() stores into
  ASXBSENV (PSA → ASCB+0x224 → ASXB+0x6C → ASXBSENV+0xC8); racf_get_acee()
  reads the same field. TCBSENV is never touched.
• libc370/src/clib/@@ctcrtx.c:87 — workers are created with
  ATTACH EP=CTHREAD; each session is a distinct TCB in the same AS
  (@@cminit.c: pool pre-spawns mintask, grows to maxtask = max_sessions).
• libc370/src/racf/racauth.c:68,120,135,148 — racf_auth() does serialize
  its own set/RACHECK/restore under lock(asxb)/unlock(asxb), so the
  primary authorization decision (FTPD's check_dataset_access() pre-check)
  is race-free. The OPEN-path switch in ftpd#mvs.c does not take that lock.

Severity

Hardening / defense-in-depth. Entitlement is gated race-free by the primary
racf_auth() pre-check under the correct identity, so for a pre-checked open the
OPEN-race yields a spurious OPEN failure (availability), not privilege
escalation. (Audit note: any fopen not preceded by a racf_auth pre-check
would rely on the racy OPEN check directly — higher concern; enumerate such
sites.)

Remedy — VERIFY FIRST, do not assume

The fix direction is not decided. First step:

1. Verify whether MVS 3.8j OPEN + RAKF actually consult TCBSENV.
   "RACROUTE honors TCBSENV over ASXBSENV" is z/OS semantics; under RAKF it is
   the security layer that decides whether TCBSENV is consulted at all, and the
   MVS 3.8j OPEN path must actually propagate it. If it is honored, a per-task
   TCBSENV switch removes the race with no serialization cost.
2. Alternative: serialize the set_acee/OPEN/restore sequence under the ASXB
   lock. Note the catch: racf_auth() proves the lock pattern for the fast
   RACHECK, but OPEN is I/O-bound — holding an AS-wide ENQ across every
   dataset OPEN would serialize all opens AS-wide and risks a throughput
   collapse / long holds. This is precisely why the current code locks only the
   RACHECK, not the OPEN.

Whichever path is chosen, ABEND recovery's ASXBSENV reset (linked PR) should be
revisited to match.

Note

Under a multi-CP Hercules configuration the interleaving becomes true
parallelism, which additionally removes any store-ordering guarantee on the
shared ASXBSENV field.

Security invariant dependency

The linked PR documents a SECURITY INVARIANT in doc/FTPD_RAKF_SETUP.md:
FTPD/USER must remain least-privilege so recovery's ASXBSENV reset stays
fail-closed. A fix here should preserve or supersede that invariant.

[mgrossmann]

Verification results for the "VERIFY FIRST" section, from RAKF source and from
a live 3.8j system. Three of this issue's premises change.

1. TCBSENV is not an option. RAKF resolves the ACEE from the caller's
parameter list, else ASXBSENV, and nothing else — RACHECK
ICHSFR00:111-115, FRACHECK :150-154, RACDEF :199-203, RACXTRT
:270-274. TCBSENV does not appear in the module. It could not, either:
SYS1.AMODGEN(IKJTCB) on MVS 3.8j has no TCBSENV and no ACEE anchor at all
— the field belongs to later TCB levels. "RACROUTE honors TCBSENV" is not just
z/OS semantics here, it is a z/OS-era control block. Raised upstream with RAKF
as a per-task-anchor request.

2. Serializing under the ASXB lock is worse than described. The switched
regions are not all OPENs: DELE, RMD and RNTO wrap a complete idcams()
invocation — a program load and run. Holding an AS-wide ENQ across that would
serialize FTPD on IDCAMS. There is also a deadlock shape: worker 1 holds the
lock and waits inside fopen on a dataset ENQ held by worker 2's open
transfer, while worker 2 waits for the lock.

3. The severity was understated, for a reason not in the issue. The
save/restore idiom stored the value observed on entry, so two workers
interleave into a state where the address space rests on a user's ACEE after
both have "restored". When that user logs out, racf_logout() finds its own
ACEE in ASXBSENV and clears the field — and RAKF treats no-ACEE as permitted
(ICHSFR00:116, BZ RACHGOOD). So the address space could end up passing
checks it should fail, with no ABEND and no operator-visible symptom. Also:
this needs no multi-CP configuration, contrary to the note at the end. Every
window waits, and a waiting TCB is exactly when a sibling gets dispatched.

#78 fixes that class by always restoring server->stc_acee instead of the
observed value, and adds the missing ALTER pre-check on the RNTO target
(RNFR only ever checked the source).

What is left is the transient window — a sibling observing another session's
identity during that session's operation — which with the pre-checks in
place costs a spurious denial rather than entitlement. Tracked in #79 with the
remaining options; the libc370 half is mvslovers/libc370#58.

The SECURITY INVARIANT in doc/FTPD_RAKF_SETUP.md is preserved: recovery
still resets to the same least-privilege STC ACEE, and that value is now also
what the normal path restores.