[
https://issues.apache.org/jira/browse/HBASE-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-3435.
-----------------------------------
Resolution: Duplicate
{quote}
Currently we store per column-family ACLs in the .META.:acl column family,
using keys in the form principal,family. We could extend this for
column-qualifier specific assignments to: principal,family,qualifier.
The next step is then enabling authorization checks per column-qualifier, which
only becomes tricky in the case of wildcard gets or scans. However, we already
have a good user-exposed facility for matching columns to return via filters.
So we would create a new AccessControlFilter and inject it (when security is
enabled) into user requests via preGet() and preScannerOpen() requests.
AccessControlFilter would then consult TableAuthManager for each KeyValue and
filter out those for which access was denied.
In the process, the current logic for rejecting requests on a column-family
level would need to change to allow requests from users with specific column
qualifier access to continue.
{quote}
I've done all of this in the context of work for HBASE-6222.
> Per-column-qualifier and per-key-value security for HBASE-3025
> --------------------------------------------------------------
>
> Key: HBASE-3435
> URL: https://issues.apache.org/jira/browse/HBASE-3435
> Project: HBase
> Issue Type: Improvement
> Components: security
> Reporter: Ed Kohlwey
>
> Security labels should be assignable on a per-key-value and
> per-column-qualifer level.
> While simply assigning labels on a k/v level provides a lot of granularity,
> there will probably be a frequent desire to store labels on a column
> qualifier level and have fast atomic transactions on labels.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
