I feel like that's the space for either refined labelling or the pluggable authorization framework. Maybe both.
If you have a piece of data that can only be seen under XOR conditions, then it should probably have a unique label which can be provided under those conditions from the authorizor. On Mon, Mar 10, 2014 at 12:40 PM, Keith Turner <[email protected]> wrote: > 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. > > >
