[
https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494750#comment-13494750
]
Andrew Purtell commented on HBASE-6222:
---------------------------------------
[~v.himanshu] Thanks for the gracious comments.
bq. Currently, all the acl entries are stored in zk (limit of znode is 1 mb);
will you be using the same approach?
No. Pursuing an incremental approach, so, we keep per-table and per-CF ACLs
implemented as-is for now. Then add per cell ACLs as a third level of
permissions checking. Per cell ACLs are stored in the region alongside the
data. It's an open question if having an ACL table will still be necessary as
things evolve.
bq. Its not clear how/where you are storing the acls at keyvalue level.
There are different approaches to doing this, will try two of them to establish
the extent of changes to core code required and performance differences:
1. Store per cell ACLs in tags in KV, using the approach to putting tags in KV
that I described above.
2. Store per cell ACLs in a "shadow ACL column". Per cell ACLs are still
associated with individual KVs but in effect tag storage is moved external to
the data KV, so no changes to the KeyValue implementation are necessary, and
stored in the same region. Will incur some additional cost for querying tags
but will not require intra cluster RPC.
3. Store per cell ACLs in the ACL table. Tag storage again is external to the
data KV, and now in a separate table. Will incur cost for querying tags and
furthermore require intra cluster RPC. Probably won't actually try this.
bq. You use acl table, or something else?
The ACL is stored "in" the KV (depends which impl option if that is physical or
logical). The table, row, family, qualifier, and timestamp of an in-KV
permission are implicit -- those of the KV's location. I do use TablePermission
to represent ACLs at the KV level but only to avoid some refactoring in the
AccessController that would be outside the scope of a proof of concept. Pardon
if mentioning this detail was confusing.
{quote}
bq. It doesn't make sense to attach an ACL on a Delete, because the KVs covered
by the delete will be ... deleted.
I don't completely agree with this but will not comment also unless I
completely understand your approach.
{quote}
We treat ACLs on a KV as timestamped like the rest of the KV. An ACL in a new
Put applies only to that Put. It doesn't change the ACL of any previous Put.
However, we require a Put to have covering[1] permission -- so either table
perms, CF perms, or perms in the most recent visible existing value, if any,
must allow the pending Put (or Append, or Increment, or any mutation) in order
for it to be applied. This is because the pending operation will replace the
visible value and its ACL, if it has one, for Gets and Scans that don't ask for
more than one version. If you actually want to change the ACL on a specific KV,
you must Delete then Put, if you have perms for that. On reads, a KV is visible
to the InternalScanner if either table perms, CF perms, or perms stored in the
KV allow, similar to visibility labels in a sense but with ACL semantics. The
AccessControlFilter is extended to do that[2]. For Deletes, _all_ visible prior
versions covered by the Delete must allow the Delete, because a major
compaction could remove them if we allow the tombstone and it covers them,
regardless of any ACL they might contain. "Visible" here is defined as not
covered by an already committed tombstone. This allows simple and
straightforward evolution of security policy over time without requiring
expensive updates[3].
So a Delete doesn't update ACLs. ACLs are bits of information to be stored with
the KV. It's meaningless to put an ACL on an op that stores nothing. And, an
ACL on a Delete would not grant that Delete permission to do something. It
would be the union of per table, per CF, and all ACLs on visible covered values
that would grant (or not). Since we are only looking at the most recent version
of a KV, if any, except for Deletes, only Delete - and especially DeleteColumn
- can be potentially expensive to check. There is no free lunch but
union-of-ACL semantics helps: Granting appropriate per table or per CF perms to
a user or group obviates the need for KV ACL checking for that user or her
groups, so we can early out and avoid going to the store in that case.
[1] Maybe "covering" isn't quite the best term. Suggestions welcome.
[2] This changes AC semantics some. A user who doesn't have permissions to a CF
or exact location (column+qualifier) just won't get values back from a scan or
get, as opposed to previous behavior which would throw an AccessDeniedException
if the user did not have required perms to the CF at the CF level. I refactored
TestAccessController to address this in a clean way.
[3] On the other hand GRANT and REVOKE commands could provide a convenient way
to change per KV ACLs too, since they are DDL not DML ops. We could consider
enhancing the GRANT and REVOKE command processing in the AccessController to
replace all per KV ACLs covered by the action, if they exist. A possible
optimization is lazy updates via a timestamped log of recent GRANTs and REVOKEs
(but I just thought of that now so it's a superficial suggestion).
> Add per-KeyValue Security
> -------------------------
>
> Key: HBASE-6222
> URL: https://issues.apache.org/jira/browse/HBASE-6222
> Project: HBase
> Issue Type: New Feature
> Components: security
> Reporter: stack
> Assignee: Andrew Purtell
> Attachments: HBaseCellRow-LevelSecurityDesignDoc.docx,
> HBaseCellRow-LevelSecurityPRD.docx
>
>
> Saw an interesting article:
> http://www.fiercegovernmentit.com/story/sasc-accumulo-language-pro-open-source-say-proponents/2012-06-14
> "The Senate Armed Services Committee version of the fiscal 2013 national
> defense authorization act (S. 3254) would require DoD agencies to foreswear
> the Accumulo NoSQL database after Sept. 30, 2013, unless the DoD CIO
> certifies that there exists either no viable commercial open source database
> with security features comparable to [Accumulo] (such as the HBase or
> Cassandra databases)..."
> Not sure what a 'commercial open source database' is, and I'm not sure whats
> going on in the article, but tra-la-la'ing, if we had per-KeyValue 'security'
> like Accumulo's, we might put ourselves in the running for federal
> contributions?
--
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
