You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by Kirby Zhou <ki...@gmail.com> on 2022/03/02 12:43:59 UTC

Review Request 73881: RANGER-3619: REST API returns 403 when authed user has no permission.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73881/
-----------------------------------------------------------

Review request for ranger.


Bugs: RANGER-3619
    https://issues.apache.org/jira/browse/RANGER-3619


Repository: ranger


Description
-------

REST API should return 403-Forbidden when authenticated client is not allowed to access API to avoid crash Ranger Clients.

 
Now, some API returns 401-Unauthorized instead of 403-Forbidden when client is already passed authentication but now allowed to do something.
In general, this will not cause any serious problems. However, there is a flaw in the SPNEGO protocol implementation of Java HTTPUrlConnection. It causes the Client to throw an unexpected exception. This will trouble the operators and developers.
 
Let me show you how it happens:
 
For example:
 
The RangerAdminClient inside KMS  want to access API "/service/secure/policies/download", but the principal is not in the allowlist.
 
RangerAdminClient is based on Jersey-Client
JerseyClient sends a HTTP-request to Ranger Service without authentication information
Tomcat/Spring inside Ranger returns 401 with HTTP header “WWW-Authentication: Neogotiate”
JerseyClient sends request again with Kerberos/SPNEGO authentication tokens.
Tomcat/Spring inside Ranger accept the authentication, then call ServiceRest::getSecureServicePoliciesIfUpdated to reply the API calling.
ServiceRest::getSecureServicePoliciesIfUpdated checks allowlist of “kms service”, and refuse client with 401.
Tomcat/Spring inside Ranger returns 401 with HTTP header “WWW-Authentication: Neogotiate….” for notifying RangerAdminClient the authentication is passed.
 
Now, there is a malformed state. HTTP-status code told client authenticate is failed, but HTTP header told client authentication is passed.
 
In the RangerAdminClient side, 
 
sun.net.www.protocol.http.HttpURLConnection.getInputStream0() see the second 401.
'inNegotiate' = true, so it is in the progress of Negotiate.
It checks that: if "WWW-Authenticate: Negotiate" exist then disable negotiate for following code to avoid try Negotiate once again.
But "WWW-Authenticate: Negotiate xczsd324…" does not the rule above.
So HttpURLConnection calls AuthenticationInfo.sendHeaders to generate a new request header.
Wow, Null exception happens.
Logs "ERROR RangerAdminRESTClient - Error getting policies; Received NULL response!!. secureMode=true, user=… (auth:KERBEROS), serviceName=kmsdev"
Log of KMS: "ERROR RangerAdminRESTClient - Failed to get response, Error is : java.lang.RuntimeException: java.lang.NullPointerException"
 
This log makes admin confused.


Diffs
-----

  security-admin/src/main/java/org/apache/ranger/biz/RangerBizUtil.java 1ec1df0a3d09577c52e503532d5aea87ad6cd72d 
  security-admin/src/main/java/org/apache/ranger/biz/XAuditMgr.java 935435044624a38ce7b0b9c7401e3f3dbacc0f65 
  security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 8109968e4d55de9e7875fb56590e50522fba32cb 
  security-admin/src/main/java/org/apache/ranger/rest/RoleREST.java e3cdef1c2ba6411cf4d4a26cd49e56e9017f3e93 
  security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 098188e3b9f1f837727c7d279a4fab1f0aa84e34 
  security-admin/src/main/java/org/apache/ranger/rest/TagREST.java 10f91e037180a50287b8d0b0fa0ea3eec0d7f415 
  security-admin/src/main/java/org/apache/ranger/rest/XUserREST.java 451805321d050dda06a0f2b66a9b945411632e2f 
  security-admin/src/main/java/org/apache/ranger/security/context/RangerPreAuthSecurityHandler.java 5d7cbdc679c010a7b88c85324e6f9912cba29fe6 
  security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerKrbFilter.java 223a991c76bae7d25f5ce89604d0a8a90d426fe5 


Diff: https://reviews.apache.org/r/73881/diff/1/


Testing
-------


Thanks,

Kirby Zhou


Re: Review Request 73881: RANGER-3619: REST API returns 403 when authed user has no permission.

Posted by bhavik patel <bh...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73881/#review224262
-----------------------------------------------------------


Ship it!




Ship It!

- bhavik patel


On April 7, 2022, 6:21 a.m., Kirby Zhou wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73881/
> -----------------------------------------------------------
> 
> (Updated April 7, 2022, 6:21 a.m.)
> 
> 
> Review request for ranger.
> 
> 
> Bugs: RANGER-3619
>     https://issues.apache.org/jira/browse/RANGER-3619
> 
> 
> Repository: ranger
> 
> 
> Description
> -------
> 
> REST API should return 403-Forbidden when authenticated client is not allowed to access API to avoid crash Ranger Clients.
> 
>  
> Now, some API returns 401-Unauthorized instead of 403-Forbidden when client is already passed authentication but not allowed to do something.
> In general, this will not cause any serious problems, but there is a flaw in the SPNEGO protocol implementation of Java HTTPUrlConnection. It causes the Client to throw an unexpected exception. This will trouble the operators and developers.
>  
> Let me show you how it happens:
>  
> For example:
>  
> The RangerAdminClient inside KMS  want to access API "/service/secure/policies/download", but the principal is not in the allowlist.
>  
> RangerAdminClient is based on Jersey-Client
> JerseyClient sends a HTTP-request to Ranger Service without authentication information
> Tomcat/Spring inside Ranger returns 401 with HTTP header “WWW-Authentication: Neogotiate”
> JerseyClient sends request again with Kerberos/SPNEGO authentication tokens.
> Tomcat/Spring inside Ranger accept the authentication, then call ServiceRest::getSecureServicePoliciesIfUpdated to reply the API calling.
> ServiceRest::getSecureServicePoliciesIfUpdated checks allowlist of “kms service”, and refuse client with 401.
> Tomcat/Spring inside Ranger returns 401 with HTTP header “WWW-Authentication: Neogotiate….” for notifying RangerAdminClient the authentication is passed.
>  
> Now, there is a malformed state. HTTP-status code told client authenticate is failed, but HTTP header told client authentication is passed.
>  
> In the RangerAdminClient side, 
>  
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0() see the second 401.
> 'inNegotiate' = true, so it is in the progress of Negotiate.
> It checks that: if "WWW-Authenticate: Negotiate" exist then disable negotiate for following code to avoid try Negotiate once again.
> But "WWW-Authenticate: Negotiate xczsd324…" does not the rule above.
> So HttpURLConnection calls AuthenticationInfo.sendHeaders to generate a new request header.
> Wow, Null exception happens.
> 
> Logs "ERROR RangerAdminRESTClient - Error getting policies; Received NULL response!!. secureMode=true, user=… (auth:KERBEROS), serviceName=kmsdev"
> 
> Log of KMS: "ERROR RangerAdminRESTClient - Failed to get response, Error is : java.lang.RuntimeException: java.lang.NullPointerException"
>  
> 
> This log makes admin confused, and no not know how to fix it.
> 
> My patch fixes the return code of http, thus avoiding these problems.
> 
> 
> Diffs
> -----
> 
>   security-admin/src/main/java/org/apache/ranger/biz/RangerBizUtil.java 1ec1df0a3d09577c52e503532d5aea87ad6cd72d 
>   security-admin/src/main/java/org/apache/ranger/biz/XAuditMgr.java 935435044624a38ce7b0b9c7401e3f3dbacc0f65 
>   security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 8109968e4d55de9e7875fb56590e50522fba32cb 
>   security-admin/src/main/java/org/apache/ranger/rest/RoleREST.java e3cdef1c2ba6411cf4d4a26cd49e56e9017f3e93 
>   security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 098188e3b9f1f837727c7d279a4fab1f0aa84e34 
>   security-admin/src/main/java/org/apache/ranger/rest/TagREST.java 10f91e037180a50287b8d0b0fa0ea3eec0d7f415 
>   security-admin/src/main/java/org/apache/ranger/rest/XUserREST.java 451805321d050dda06a0f2b66a9b945411632e2f 
>   security-admin/src/main/java/org/apache/ranger/security/context/RangerPreAuthSecurityHandler.java 5d7cbdc679c010a7b88c85324e6f9912cba29fe6 
>   security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerKrbFilter.java 223a991c76bae7d25f5ce89604d0a8a90d426fe5 
> 
> 
> Diff: https://reviews.apache.org/r/73881/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Kirby Zhou
> 
>


Re: Review Request 73881: RANGER-3619: REST API returns 403 when authed user has no permission.

Posted by Ramesh Mani <rm...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73881/#review224327
-----------------------------------------------------------


Ship it!




Ship It!

- Ramesh Mani


On April 7, 2022, 6:21 a.m., Kirby Zhou wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73881/
> -----------------------------------------------------------
> 
> (Updated April 7, 2022, 6:21 a.m.)
> 
> 
> Review request for ranger.
> 
> 
> Bugs: RANGER-3619
>     https://issues.apache.org/jira/browse/RANGER-3619
> 
> 
> Repository: ranger
> 
> 
> Description
> -------
> 
> REST API should return 403-Forbidden when authenticated client is not allowed to access API to avoid crash Ranger Clients.
> 
>  
> Now, some API returns 401-Unauthorized instead of 403-Forbidden when client is already passed authentication but not allowed to do something.
> In general, this will not cause any serious problems, but there is a flaw in the SPNEGO protocol implementation of Java HTTPUrlConnection. It causes the Client to throw an unexpected exception. This will trouble the operators and developers.
>  
> Let me show you how it happens:
>  
> For example:
>  
> The RangerAdminClient inside KMS  want to access API "/service/secure/policies/download", but the principal is not in the allowlist.
>  
> RangerAdminClient is based on Jersey-Client
> JerseyClient sends a HTTP-request to Ranger Service without authentication information
> Tomcat/Spring inside Ranger returns 401 with HTTP header “WWW-Authentication: Neogotiate”
> JerseyClient sends request again with Kerberos/SPNEGO authentication tokens.
> Tomcat/Spring inside Ranger accept the authentication, then call ServiceRest::getSecureServicePoliciesIfUpdated to reply the API calling.
> ServiceRest::getSecureServicePoliciesIfUpdated checks allowlist of “kms service”, and refuse client with 401.
> Tomcat/Spring inside Ranger returns 401 with HTTP header “WWW-Authentication: Neogotiate….” for notifying RangerAdminClient the authentication is passed.
>  
> Now, there is a malformed state. HTTP-status code told client authenticate is failed, but HTTP header told client authentication is passed.
>  
> In the RangerAdminClient side, 
>  
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0() see the second 401.
> 'inNegotiate' = true, so it is in the progress of Negotiate.
> It checks that: if "WWW-Authenticate: Negotiate" exist then disable negotiate for following code to avoid try Negotiate once again.
> But "WWW-Authenticate: Negotiate xczsd324…" does not the rule above.
> So HttpURLConnection calls AuthenticationInfo.sendHeaders to generate a new request header.
> Wow, Null exception happens.
> 
> Logs "ERROR RangerAdminRESTClient - Error getting policies; Received NULL response!!. secureMode=true, user=… (auth:KERBEROS), serviceName=kmsdev"
> 
> Log of KMS: "ERROR RangerAdminRESTClient - Failed to get response, Error is : java.lang.RuntimeException: java.lang.NullPointerException"
>  
> 
> This log makes admin confused, and no not know how to fix it.
> 
> My patch fixes the return code of http, thus avoiding these problems.
> 
> 
> Diffs
> -----
> 
>   security-admin/src/main/java/org/apache/ranger/biz/RangerBizUtil.java 1ec1df0a3d09577c52e503532d5aea87ad6cd72d 
>   security-admin/src/main/java/org/apache/ranger/biz/XAuditMgr.java 935435044624a38ce7b0b9c7401e3f3dbacc0f65 
>   security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 8109968e4d55de9e7875fb56590e50522fba32cb 
>   security-admin/src/main/java/org/apache/ranger/rest/RoleREST.java e3cdef1c2ba6411cf4d4a26cd49e56e9017f3e93 
>   security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 098188e3b9f1f837727c7d279a4fab1f0aa84e34 
>   security-admin/src/main/java/org/apache/ranger/rest/TagREST.java 10f91e037180a50287b8d0b0fa0ea3eec0d7f415 
>   security-admin/src/main/java/org/apache/ranger/rest/XUserREST.java 451805321d050dda06a0f2b66a9b945411632e2f 
>   security-admin/src/main/java/org/apache/ranger/security/context/RangerPreAuthSecurityHandler.java 5d7cbdc679c010a7b88c85324e6f9912cba29fe6 
>   security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerKrbFilter.java 223a991c76bae7d25f5ce89604d0a8a90d426fe5 
> 
> 
> Diff: https://reviews.apache.org/r/73881/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Kirby Zhou
> 
>


Re: Review Request 73881: RANGER-3619: REST API returns 403 when authed user has no permission.

Posted by Kirby Zhou <ki...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73881/
-----------------------------------------------------------

(Updated 四月 7, 2022, 6:21 a.m.)


Review request for ranger.


Bugs: RANGER-3619
    https://issues.apache.org/jira/browse/RANGER-3619


Repository: ranger


Description (updated)
-------

REST API should return 403-Forbidden when authenticated client is not allowed to access API to avoid crash Ranger Clients.

 
Now, some API returns 401-Unauthorized instead of 403-Forbidden when client is already passed authentication but not allowed to do something.
In general, this will not cause any serious problems, but there is a flaw in the SPNEGO protocol implementation of Java HTTPUrlConnection. It causes the Client to throw an unexpected exception. This will trouble the operators and developers.
 
Let me show you how it happens:
 
For example:
 
The RangerAdminClient inside KMS  want to access API "/service/secure/policies/download", but the principal is not in the allowlist.
 
RangerAdminClient is based on Jersey-Client
JerseyClient sends a HTTP-request to Ranger Service without authentication information
Tomcat/Spring inside Ranger returns 401 with HTTP header “WWW-Authentication: Neogotiate”
JerseyClient sends request again with Kerberos/SPNEGO authentication tokens.
Tomcat/Spring inside Ranger accept the authentication, then call ServiceRest::getSecureServicePoliciesIfUpdated to reply the API calling.
ServiceRest::getSecureServicePoliciesIfUpdated checks allowlist of “kms service”, and refuse client with 401.
Tomcat/Spring inside Ranger returns 401 with HTTP header “WWW-Authentication: Neogotiate….” for notifying RangerAdminClient the authentication is passed.
 
Now, there is a malformed state. HTTP-status code told client authenticate is failed, but HTTP header told client authentication is passed.
 
In the RangerAdminClient side, 
 
sun.net.www.protocol.http.HttpURLConnection.getInputStream0() see the second 401.
'inNegotiate' = true, so it is in the progress of Negotiate.
It checks that: if "WWW-Authenticate: Negotiate" exist then disable negotiate for following code to avoid try Negotiate once again.
But "WWW-Authenticate: Negotiate xczsd324…" does not the rule above.
So HttpURLConnection calls AuthenticationInfo.sendHeaders to generate a new request header.
Wow, Null exception happens.

Logs "ERROR RangerAdminRESTClient - Error getting policies; Received NULL response!!. secureMode=true, user=… (auth:KERBEROS), serviceName=kmsdev"

Log of KMS: "ERROR RangerAdminRESTClient - Failed to get response, Error is : java.lang.RuntimeException: java.lang.NullPointerException"
 

This log makes admin confused, and no not know how to fix it.

My patch fixes the return code of http, thus avoiding these problems.


Diffs
-----

  security-admin/src/main/java/org/apache/ranger/biz/RangerBizUtil.java 1ec1df0a3d09577c52e503532d5aea87ad6cd72d 
  security-admin/src/main/java/org/apache/ranger/biz/XAuditMgr.java 935435044624a38ce7b0b9c7401e3f3dbacc0f65 
  security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 8109968e4d55de9e7875fb56590e50522fba32cb 
  security-admin/src/main/java/org/apache/ranger/rest/RoleREST.java e3cdef1c2ba6411cf4d4a26cd49e56e9017f3e93 
  security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 098188e3b9f1f837727c7d279a4fab1f0aa84e34 
  security-admin/src/main/java/org/apache/ranger/rest/TagREST.java 10f91e037180a50287b8d0b0fa0ea3eec0d7f415 
  security-admin/src/main/java/org/apache/ranger/rest/XUserREST.java 451805321d050dda06a0f2b66a9b945411632e2f 
  security-admin/src/main/java/org/apache/ranger/security/context/RangerPreAuthSecurityHandler.java 5d7cbdc679c010a7b88c85324e6f9912cba29fe6 
  security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerKrbFilter.java 223a991c76bae7d25f5ce89604d0a8a90d426fe5 


Diff: https://reviews.apache.org/r/73881/diff/1/


Testing
-------


Thanks,

Kirby Zhou