Jerry He created HBASE-12346:
--------------------------------

             Summary: Scan's default auths behavior under Visibility labels
                 Key: HBASE-12346
                 URL: https://issues.apache.org/jira/browse/HBASE-12346
             Project: HBase
          Issue Type: Bug
          Components: API, security
    Affects Versions: 0.99.1, 0.98.7
            Reporter: Jerry He


In Visibility Labels security, a set of labels (auths) are administered and 
associated with a user.
A user can normally  only see cell data during scan that are part of the user's 
label set (auths).
Scan uses setAuthorizations to indicates its wants to use the auths to access 
the cells.
Similarly in the shell:
{code}
scan 'table1', AUTHORIZATIONS => ['private']
{code}
But it is a surprise to find that setAuthorizations seems to be 'mandatory' in 
the default visibility label security setting.  Every scan needs to 
setAuthorizations before the scan can get any cells even the cells are under 
the labels the request user is part of.

The following steps will illustrate the issue:

Run as superuser.
{code}
1. create a visibility label called 'private'
2. create 'table1'
3. put into 'table1' data and label the data as 'private'
4. set_auths 'user1', 'private'
5. grant 'user1', 'RW', 'table1'
{code}
Run as 'user1':
{code}
1. scan 'table1'
This show no cells.
2. scan 'table1', scan 'table1', AUTHORIZATIONS => ['private']
This will show all the data.
{code}

I am not sure if this is expected by design or a bug.
But a more reasonable, more client application backward compatible, and less 
surprising default behavior should probably look like this:

A scan's default auths, if its Authorizations attributes is not set explicitly, 
should be all the auths the request user is administered and allowed on the 
server.

If scan.setAuthorizations is used, then the server further filter the auths 
during scan: use the input auths minus what is not in user's label set on the 
server.






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to