Mailing-List: contact dev-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zookeeper.apache.org
From: bhupendra jain <bhupendra.jain@huawei.com>
To: "dev@zookeeper.apache.org" <dev@zookeeper.apache.org>
Subject: Regarding Super user check inconsistency 
Thread-Topic: Regarding Super user check inconsistency 
Thread-Index: AdLjX9dks4bbHq3FRtC5f2FJYNYRsQ==
Date: Mon, 12 Jun 2017 09:40:20 +0000
Message-ID: <2EC33BF9CF5EAF4399852F9B6F9E948E728C110B@DGGEMA501-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_2EC33BF9CF5EAF4399852F9B6F9E948E728C110BDGGEMA501MBXchi_"
MIME-Version: 1.0
archived-at: Mon, 12 Jun 2017 09:40:50 -0000

--_000_2EC33BF9CF5EAF4399852F9B6F9E948E728C110BDGGEMA501MBXchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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 th=
e 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 =3D a.getId();

            if ((a.getPerms() & perm) !=3D 0) {

                if (id.getScheme().equals("world")

                        && id.getId().equals("anyone")) {

                    return;

                }

                AuthenticationProvider ap =3D ProviderRegistry.getProvider(=
id

                        .getScheme());

                if (ap !=3D 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 configu=
red for that super user, the ACL check will not pass. But for Digest it wil=
l pass even though ACL is not configured.

I think , there should be separate super user check based on all the auth p=
roviders.  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 configure=
d , sets the scheme as "Super"
IP:   No super user concept
Custom:   Custom logic.   One way is that custom auth provider sets the sch=
eme 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 f=
or admin check such as this JIRA  https://issues.apache.org/jira/browse/ZOO=
KEEPER-2014

Regards
Bhupendra


________________________________
This e-mail and its attachments contain confidential information from HUAWE=
I, 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, b=
ut not limited to, total or partial disclosure, reproduction, or disseminat=
ion) 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 im=
mediately and delete it!


--_000_2EC33BF9CF5EAF4399852F9B6F9E948E728C110BDGGEMA501MBXchi_--