[
https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396972#comment-13396972
]
Andrew Purtell edited comment on HBASE-6222 at 6/19/12 6:39 PM:
----------------------------------------------------------------
Correct me if I'm wrong but given all of the above discussion therefore the
scope of changes necessary are:
* Add a facility for storing string tags with each KV. Will need to do this for
both puts and deletes.
* Update the KV comparators to take into account tags in the sort order, if
present.
* Add a coprocessor (perhaps another implementation of Constraint) that:
** Implements a visibility filter that evaluates for each KV if the current set
of user-supplied labels intersects with allowed labels according to visibility
predicates stored in the KV, if any, and emits (or not);
** Unpacks labels added by the client via our generic op attributes facility
and adds them to KVs in a mutator op or programs the visibility filter on a Get
or Scan;
** Always adds the visibility filter to Get and Scan operations, wrapping any
other supplied filter with FilterList(MUST_PASS_ALL) and the visibility filter
on the RHS so we can let the other filters reduce the number of visibility
evaluations necessary.
* Shell support
** Add setuaths and getauths equivalent shell commands
** Extend the other shell ops with sugar for adding labels as a working example
of how to do it via the Java client
** Table create command sugar that adds the Constraint specification without a
lot of user typing necessary?
And the constraints on implementation are:
* Tag storage optimized out if no tags present
* Compartmentalized changes
* The mechanism for adding, reading, removing, and modifying tags in the KV
should be generic
Does that about sum it up?
@Laxman: Such a Constraint-based coprocessor as described would be orthogonal
to AccessController. One could use both at the same time independently, or they
could be unified at some point.
@Lars
{quote}
bq. @Andy: Compartmentalized changes
Agreed, we add a new type and handle that case separately. Though the majority
of the code is shared, the new type would trigger the extraction of the tags if
called for (which I assume would be done lazily).
{quote}
So one new type that causes us to extract tags then recurse on the actual
wrapped op? And we extend all necessary internal method signatures to carry
tags around? Edit: By that I mean a pointer to where they are serialized in
byte[] if doing it lazily as you suggest.
was (Author: apurtell):
Correct me if I'm wrong but given all of the above discussion therefore the
scope of changes necessary are:
* Add a facility for storing string tags with each KV. Will need to do this for
both puts and deletes.
* Update the KV comparators to take into account tags in the sort order, if
present.
* Add a coprocessor (perhaps another implementation of Constraint) that:
** Implements a visibility filter that evaluates for each KV if the current set
of user-supplied labels intersects with allowed labels according to visibility
predicates stored in the KV, if any, and emits (or not);
** Unpacks labels added by the client via our generic op attributes facility
and adds them to KVs in a mutator op or programs the visibility filter on a Get
or Scan;
** Always adds the visibility filter to Get and Scan operations, wrapping any
other supplied filter with FilterList(MUST_PASS_ALL) and the visibility filter
on the RHS so we can let the other filters reduce the number of visibility
evaluations necessary.
* Shell support
** Add setuaths and getauths equivalent shell commands
** Extend the other shell ops with sugar for adding labels as a working example
of how to do it via the Java client
** Table create command sugar that adds the Constraint specification without a
lot of user typing necessary?
And the constraints on implementation are:
* Tag storage optimized out if no tags present
* Compartmentalized changes
* The mechanism for adding, reading, removing, and modifying KVs should be
generic
Does that about sum it up?
@Laxman: Such a Constraint-based coprocessor as described would be orthogonal
to AccessController. One could use both at the same time independently, or they
could be unified at some point.
@Lars
{quote}
bq. @Andy: Compartmentalized changes
Agreed, we add a new type and handle that case separately. Though the majority
of the code is shared, the new type would trigger the extraction of the tags if
called for (which I assume would be done lazily).
{quote}
So one new type that causes us to extract tags then recurse on the actual
wrapped op? And we extend all necessary internal method signatures to carry
tags around? Edit: By that I mean a pointer to where they are serialized in
byte[] if doing it lazily as you suggest.
> 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
>
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
