[ 
https://issues.apache.org/jira/browse/HADOOP-19574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18024229#comment-18024229
 ] 

ASF GitHub Bot commented on HADOOP-19574:
-----------------------------------------

stoty commented on PR #7892:
URL: https://github.com/apache/hadoop/pull/7892#issuecomment-3359676121

   > wow, this is a big patch. but we need it, don't we?
   
   Yes. IMO the Java language development process has really dropped the ball 
here.
   Changing the Subject APIs while providing replacements is one thing, but 
breaking the whole Java authorization model was a big mistake.
   
   Strictly speaking we don't need to convert EVERY Thread instance, especially 
in the non-secure tests, but figuring out the cases where we can safely drop 
the Subject / UGI from the new Thread would be super hard and error-prone (and 
also fragile in case authenticated operations are added later there).
   
   > 
   > only looked at it briefly -will need to go through the full change before 
approval but I don't see any reason to block the change so far
   
   




> Restore Subject propagation semantics for Java 22+
> --------------------------------------------------
>
>                 Key: HADOOP-19574
>                 URL: https://issues.apache.org/jira/browse/HADOOP-19574
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: Istvan Toth
>            Assignee: Istvan Toth
>            Priority: Critical
>              Labels: pull-request-available
>
> Java 22 breaks Subject propagation for new Threads (when SecurityManager is 
> not enabled).
> Previously, the Subject set by Subject.doAs() / Subject.callAs() 
> automatically propagated to any new Threads created (via new Thread(), not 
> Executors).
> With JDK22, this is no longer the case, new Threads do NOT inherit the 
> Subject.
> As Hadoop heavily relies on the original behavior, we somehow need to solve 
> this problem.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to