lcx412 commented on PR #29874: URL: https://github.com/apache/flink/pull/29874#issuecomment-6812065912
Thanks @gaborgsomogyi — you were right. `SecurityUtils.install` should remain unconditional, and my original explanation was not precise enough. I have since found the actual failure path: a job running in Kubernetes application mode reproduced the expiry. The refresh created a new token, but the long-lived `FileSystemJobResultStore` / checkpoint `DFSClient` kept using the startup token. The version-specific trigger appears to be `FLINK-27204` (1.19+): `FileSystemJobResultStore` I/O was moved onto the shared `cluster-io` executor, and `DefaultDelegationTokenManager` uses the same executor for periodic token refresh. A thread-pool worker inherits the `AccessControlContext`/Subject of the first submitting thread, so `UserGroupInformation.getCurrentUser()` in the receiver can differ from the UGI captured by the client. I verified this with a minimal JVM probe: a pool created under Subject A but first submitted under Subject B runs subsequent tasks under Subject B. This change alone is not sufficient: I built and deployed a version containing this change in Kubernetes application mode. It logged `Security configuration is already installed` and skipped the second installation, but the job still hit the 24h delegation-token deadline. I will close this PR rather than present it as the fix. I will update FLINK-41435 to reflect the actual root cause and come back with a focused PR that makes the delegation-token receiver/provider target the security-context/login UGI explicitly, with a regression test. Thanks for pushing back on the original approach. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
