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

Wei-Chiu Chuang commented on HDDS-6467:
---------------------------------------

I bumped into this issue the other day and tried to fix it to no avil.

Followed this doc 
https://github.com/apache/ozone/blob/master/hadoop-hdds/docs/content/security/SecuringOzoneHTTP.md
 to configure ozone.http.filter.initializers = 
org.apache.hadoop.security.AuthenticationFilterInitializer

If you look at the OM role log, you will notice its HttpServer2 does not apply 
SPNEGO filter to the end points, which is why it's unable to authenticate. 
Possibly the solution would be to flip the last argument to this line to true: 
https://github.com/apache/ozone/blob/master/hadoop-hdds/framework/src/main/java/org/apache/hadoop/hdds/server/http/HttpServer2.java#L849C5-L849C23
 But I suspect it's going to break other things.

I am aware of changes made in Hadoop HttpServer2 in the past 2-3 years and some 
of them may be related.

> OzoneManager /loglevel endpoint authentication is not working
> -------------------------------------------------------------
>
>                 Key: HDDS-6467
>                 URL: https://issues.apache.org/jira/browse/HDDS-6467
>             Project: Apache Ozone
>          Issue Type: Bug
>          Components: OM
>    Affects Versions: 1.3.0
>            Reporter: Siyao Meng
>            Assignee: Muskan Mishra
>            Priority: Major
>
> This might not be limited to OM, could affect SCM and others as well as they 
> may share the logic.
> Repro:
> 1. kinit authenticated with Kerberos as user {{om}}
> 2. Then curl, but endpoint returns 403 Forbidden:
> {code:bash}
> $ curl -k --negotiate -u : 
> "https://<OM_HOST>:9875/logLevel?log=org.apache.hadoop.security.UserGroupInformation"
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
> <title>Error 403 Unauthenticated users are not authorized to access this 
> page.</title>
> </head>
> <body><h2>HTTP ERROR 403 Unauthenticated users are not authorized to access 
> this page.</h2>
> <table>
> <tr><th>URI:</th><td>/logLevel</td></tr>
> <tr><th>STATUS:</th><td>403</td></tr>
> <tr><th>MESSAGE:</th><td>Unauthenticated users are not authorized to access 
> this page.</td></tr>
> <tr><th>SERVLET:</th><td>logLevel</td></tr>
> </table>
> </body>
> </html>
> {code}
> OM log prints the user name is {{dr.who}}:
> {code}
> 2022-03-17 04:26:10,916 WARN org.apache.hadoop.http.HttpServer2: User dr.who 
> is unauthorized to access the page /logLevel.
> 2022-03-17 04:26:16,378 WARN org.apache.hadoop.http.HttpServer2: User dr.who 
> is unauthorized to access the page /logLevel.
> {code}
> The {{/, /stacks, /jmx, /conf}} endpoints are working just fine. But these 
> four doesn't seem to require auth at all (works even after {{kdestroy}} or 
> without {{--negotiate -u :}}) on the cluster:
> {code:bash}
> $ curl -k --negotiate -u : "https://<OM_HOST>:9875/"
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
>         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> <!--
>    Licensed to the Apache Software Foundation (ASF) under one or more
> ...
> {code}
> Above test is conducted on an actual cluster. Should be able to repro in 
> {{ozonesecure}} docker as well if it enables SPNEGO/SSL.
> curl -v doesn't show any {{gss_init_sec_context() failed: : No Kerberos 
> credentials available}} message, indicating the server doesn't ask for SPNEGO 
> auth at all.
> A correct SPNEGO negotiation should have {{Authorization: Negotiate AAA}} 
> header from client to server, then {{WWW-Authenticate: Negotiate BBB}} from 
> server to client.
> It seems {{request.getRemoteUser()}} in this check is incorrectly returning 
> the user as {{dr.who}} here:
> https://github.com/apache/hadoop/blob/branch-3.3.1/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/http/HttpServer2.java#L1569-L1583



--
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