[
https://issues.apache.org/jira/browse/HBASE-12346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189673#comment-14189673
]
Jerry He commented on HBASE-12346:
----------------------------------
Hi, [~apurtell]
As long as we agree on the external default behavior, how we do it is internal
implementation. I am fine with either approach: single SLG or stacked SLGs.
Here is what we want to expose as the default behavior that we seem to agree on:
1. If there is no Auths in the scan, we will get the defined set for the user
from the labels table.
2. If there is Auths in the scan, we will examine the passed in Auths and drop
the ones that the user is not entitled to. Then use the resulting label set.
I was thinking about stacked approach since you first mentioned it.
It does not seem to be an easy thing to do it elegantly if we think closely
given the current stacking design.
A SLG to copies the auths from the scan is only a 'pass thru' SLG. It does not
seem to help to use it in a stack.
The design I can come up to accomplish the above default behavior is the
following:
1. Something similar to EnforcingScanLabelGenerator as the first SLG. But we
need to change it a little:
a. Get the defined set for the user from the labels table ONLY IF the auths
in the scan is null.
b. Otherwise does nothing, pass on the auths in the scan to the next SLG.
2. The current DefaultScanLabelGenerator (without the patch) as the second SLG.
This SLG will filter/drop labels from the passed in Auths as needed.
Maybe I didn't completely understand what you meant in the above comment
regarding the two SLGs :-)
Please advise. Thanks.
> 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.98.7, 0.99.1
> Reporter: Jerry He
> Fix For: 0.98.8, 0.99.2
>
> Attachments: HBASE-12346-master-v2.patch, HBASE-12346-master.patch
>
>
> 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)
