On 3/10/14, 12:19 PM, Sean Busbey wrote:
+dev@accumulo We may be getting into the weeds enough to remove user@accumulo, but I'll leave in place for now. inline below On Mon, Mar 10, 2014 at 11:10 AM, Keith Turner <[email protected] <mailto:[email protected]>> wrote: On Mon, Mar 10, 2014 at 11:50 AM, Sean Busbey <[email protected] <mailto:[email protected]>> wrote: Phil, What John is getting at here is that since Accumulo's security label model is trying to enforce role presence, our APIs allow a user to request that only a subset of their authorizations be used in a given request. The ability to request only a subset of authorizations on a per-request basis is needed to implement some common Accumulo use cases (such as a trusted application filtering for a variety of users in an multi-level security environment). To safely add not, it seems like we would also need to add the concept of a minimal authorization set. Currently an Accumulo user has a maximum set of authorizations they can query. However they can choose to use any subset of this including the empty set. For exmaple Accumulo user doc has a maximum authorization set of (doctor, researcher) and a minimal set (doctor). So every scan must specify at least 'doctor' or it will fail. This seems very complicated and easy for users to get wrong. I agree that this is adding a significant amount of complexity. One option would be to annotate NOT as advisory, or to specify in the docs that it'd be up to the application layer to enforce the inclusion of the minimal set. (then again, that leaves even more room for erroneous implementations) Does anyone have time to review the design docs from HBase's implementation of cell level visibilities? I know their visibility parsing allows NOT and I'm wondering if they worked through this already.
A quick glance: it doesn't really look like they considered this (or a few other things we specifically avoided), but I haven't thoroughly read everything (there was a lot of discussion).
One of the design docs[1] referenced making "a super-user visibility that can see all other visibilities".
Dropping authorizations that the user doesn't have is also a divergence, where we fail loudly (Exception) at them. [2]
[1] https://issues.apache.org/jira/secure/attachment/12552508/HBaseCellRow-LevelSecurityPRD.docx [2] https://communities.intel.com/community/itpeernetwork/datastack/blog/2013/10/29/hbase-cell-security
