On Mon, Mar 10, 2014 at 12:19 PM, Sean Busbey <[email protected]>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]> wrote: > > > > > > > > > On Mon, Mar 10, 2014 at 11:50 AM, Sean Busbey <[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) > If we are going to do it, I think we should try to come up with a design that solves end-to-end use cases. The not op seems useful but also dangerous, there is a real possibility of unintended data leakage. A minimal authorization set is a solution. Are there other solutions? Ones that better translate a users intent into constraints in the system. > > 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. >
