Question
APL least-privilege sessions after password expiry: diagnosing when access actually ends
Ira Moss
0 reputation · 23 Feb 2020, 02:04 UTC
78.2K views
Loading…
0 reputation · 23 Feb 2020, 02:04 UTC
Least-privilege access in APL is commonly expressed through individual accounts listed by ⎕USERS, with each account's password supplied through ⎕PW. Expiry is governed by ⎕PWEXPIRE, after which authentication attempts using the old password are expected to be rejected.
The unresolved point is session scope. It is not clear from the documented behavior whether an expiry event invalidates sessions that are already authenticated, or whether the credential remains usable until the next login. The distinction matters when a long-running APL process holds privileges that a policy intends to revoke.
Two constraints complicate a definitive answer: expiry semantics may vary by Dyalog APL release, and ⎕USERS handling is not identical across distributions. External directories such as LDAP are not natively integrated, so any bridge sits outside the interpreter's own checks. Verification should therefore start with the language reference for the installed version, then a controlled test using a non-zero expiry value.
⎕PWEXPIRE terminate an existing authenticated session, or only block subsequent logins?35275 reputation · 23 Feb 2020, 08:40 UTC
In Dyalog APL, ⎕PWEXPIRE is evaluated at authentication time. It blocks subsequent logins using an expired password; it does not terminate a session that has already been authenticated. A long-running APL process retains its privileges after the expiry timestamp passes.
Confirmed in the supplied planning context: ⎕PWEXPIRE stores a per-user expiry timestamp, and the interpreter checks it during the ⎕PW authentication step. The core interpreter does not automatically end an established session when that timestamp is reached.
Likely explanation: The session continues until the process exits (for example via ⎕OFF or workspace unload) or until an operation explicitly triggers re-authentication. Ordinary APL code execution does not re-invoke the login check.
The planning context points to Dyalog APL Language Reference entries for versions 14.0–20.x describing expiry as affecting the next login, with release notes around version 17.0 noting that expiry does not interrupt running threads. Non-Dyalog implementations, distributions with modified ⎕USERS handling, or external authentication bridges (LDAP, PAM) may behave differently.
apl)ver and consult the Language Reference for that release. Check the ⎕PWEXPIRE entry for wording about "next login" or equivalent.⎕PWEXPIRE for a disposable test account.⎕PW. If it succeeds, the session outlived the credential.⎕OFF then a fresh login) to confirm the new attempt is rejected.Does your environment wrap privileged calls in a custom re-login wrapper, or authenticate through an external bridge such as LDAP or PAM? If yes, expiry may effectively revoke access sooner because the bridge performs its own session validation. If no, the native interpreter boundary applies, and least-privilege revocation must be handled outside ⎕PWEXPIRE—for example by terminating the session or removing the account.
Because release wording and distribution patches can shift the exact boundary, treat the controlled test above as the authoritative check for your installation.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.