Hi Devs
            In case of secure cluster, we allow the HBase clients to read the zk nodes by providing the global read permissions to all for certain nodes. These nodes are the master address znode, root server znode and the clusterId znode. In ZKUtil.createACL() , we can see these node names are specially handled.

But there are some other client side admin APIs which makes a read call into the zookeeper from the client. This include the isTableEnaled() call (May be some other. I have seen this).  Here the client directly reads a node in the zookeeper ( node created for this table ) and the data is matched to know whether this is enabled or not.

Now in secure cluster case any client can read zookeeper nodes which it needs for its normal operation like the master address and root server address.  But what if the client calls this API? [isTableEnaled () ]. I think this will be an issue.

-Anoop-

Anoop:
I think what you describe below is legitimate concern.
Can you log a JIRA for this ?

Thanks

On Tue, May 22, 2012 at 5:11 AM, Anoop Sam John <[EMAIL PROTECTED]> wrote:

> Hi Devs
>            In case of secure cluster, we allow the HBase clients to read
> the zk nodes by providing the global read permissions to all for certain
> nodes. These nodes are the master address znode, root server znode and the
> clusterId znode. In ZKUtil.createACL() , we can see these node names are
> specially handled.
>
>
>
> But there are some other client side admin APIs which makes a read call
> into the zookeeper from the client. This include the isTableEnaled() call
> (May be some other. I have seen this).  Here the client directly reads a
> node in the zookeeper ( node created for this table ) and the data is
> matched to know whether this is enabled or not.
>
> Now in secure cluster case any client can read zookeeper nodes which it
> needs for its normal operation like the master address and root server
> address.  But what if the client calls this API? [isTableEnaled () ]. I
> think this will be an issue.
>
>
>
> -Anoop-
>
>
>

Since certain znodes are accessed by the client directly they must be
marked as readable by everyone, otherwise you get a NoAuth exception from
zookeeper since nodes are created by hbase and acl is set as
CREATOR_ALL_ACL. (patch available HBASE-6068)

Here a list of client methods that uses zookeeper directly, hbase shell
uses zookeeper directly to do the zk_dump.
HBaseAdmin.checkHBaseAvailable() -> exists() /hbase
ZKTable.populateTableStates() -> listChildrenNoWatch() /hbase/table/* znodes
ZKTable.getTableState() -> getData() /hbase/table/<table name>
HConnectionManager.getCurrentNrHRS() -> getNumberOfChildren() -> /hbase/rs/
shell zk_dump -> listChildrenNoWatch() /hbase/backup-masters/*

On Tue, May 22, 2012 at 2:11 PM, Anoop Sam John <[EMAIL PROTECTED]> wrote:

> Hi Devs
>            In case of secure cluster, we allow the HBase clients to read
> the zk nodes by providing the global read permissions to all for certain
> nodes. These nodes are the master address znode, root server znode and the
> clusterId znode. In ZKUtil.createACL() , we can see these node names are
> specially handled.
>
> But there are some other client side admin APIs which makes a read call
> into the zookeeper from the client. This include the isTableEnaled() call
> (May be some other. I have seen this).  Here the client directly reads a
> node in the zookeeper ( node created for this table ) and the data is
> matched to know whether this is enabled or not.
>
> Now in secure cluster case any client can read zookeeper nodes which it
> needs for its normal operation like the master address and root server
> address.  But what if the client calls this API? [isTableEnaled () ]. I
> think this will be an issue.
>