zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Han <h...@cloudera.com>
Subject Re: Regarding Super user check inconsistency
Date Mon, 12 Jun 2017 18:39:15 GMT
Hi Bhupendra,

I think it is a known issue that SASL does not support super user.
ZOOKEEPER-1782 had a patch to fix this, but the patch never landed. The
patch seems reasonable, maybe you can create a PR based on the patch?

>> there should be separate super user check based on all the auth providers
Digest and X509 should already support superuser and the way they did is
pretty consistent by having the auth scheme set as "super". SASL superuser
can be added in a similar way (which is what ZOOKEEPER-1782 did actually)
by materializing SASL super user with same auth scheme "super", so we can
still use existing superuser ACL check.


On Mon, Jun 12, 2017 at 2:40 AM, bhupendra jain <bhupendra.jain@huawei.com>
wrote:

> HI
> I have some doubts on  the contract of super user in Zookeeper ..  as I
> see the c ode , Different auth provider has different mechanism to identify
> the super user.
>
> When ACL check happens,
>
> -          Based on scheme "Super" it considers the user as super user.
>
> for (Id authId : ids) {
>
>             if (authId.getScheme().equals("super")) {
>
>                 return;
>
>             }
>
>         }
>
> -          If scheme is not super, then first it checks the permission and
> then call the AuthProvider to validate the ACL
>
> for (ACL a : acl) {
>
>             Id id = a.getId();
>
>             if ((a.getPerms() & perm) != 0) {
>
>                 if (id.getScheme().equals("world")
>
>                         && id.getId().equals("anyone")) {
>
>                     return;
>
>                 }
>
>                 AuthenticationProvider ap = ProviderRegistry.getProvider(
> id
>
>                         .getScheme());
>
>                 if (ap != null) {
>
>                     for (Id authId : ids) {
>
>                         if (authId.getScheme().equals(id.getScheme())
>
>                                 && ap.matches(authId.getId(), id.getId()))
> {
>
>                             return;
>
>                         }
>
>                     }
>
>                 }
>
>             }
>
>         }
>
>
>
> In case scheme is SASL and its super user but ACL is not explicitly
> configured for that super user, the ACL check will not pass. But for Digest
> it will pass even though ACL is not configured.
>
> I think , there should be separate super user check based on all the auth
> providers.  Current contract of each auth provider is as below :
>
> Digest : Based on superDigest configured, Sets the Scheme as "Super"
> SASL:     checks the ACL based on zookeeper.superUser parameter and if
> user name is "super"
> X509:     Based on zookeeper.X509AuthenticationProvider.superUser
> configured , sets the scheme as "Super"
> IP:   No super user concept
> Custom:   Custom logic.   One way is that custom auth provider sets the
> scheme as "super"
>
> So I think,
>
> -          Either in AuthProvider interface we should have one more method
> to let AuthProvider check whether user is super user
>
> boolean isSuperUser(Id authID);
>
> -          OR each auth provider should set the scheme as "Super" for
> super user and handle SASL as a special case.  ( So in checkACL we need to
> have specific validation for sasl)
>
>
> I think if we have a clear contract, then same can be added at all places
> for admin check such as this JIRA  https://issues.apache.org/
> jira/browse/ZOOKEEPER-2014
>
> Regards
> Bhupendra
>
>
> ________________________________
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by phone or email immediately and delete it!
>
>
>


-- 
Cheers
Michael.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message