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). As a side effect of this ability, a particular user who is aware of your negated labels could simply request that only one of their two overlapping authorizations be considered. In Josh's example, a user could request that all of their queries carry only the "mailman" authorization and not whatever "doctor" authorization they had been added to by an administrator (presuming they held both). -Sean On Mon, Mar 10, 2014 at 10:24 AM, John Vines <[email protected]> wrote: > Your case for exclusivity also breaks when you take into account users > having the intersection of visibilities they have access to and > visibilities they are requesting to use. > > > On Mon, Mar 10, 2014 at 11:00 AM, Philip A Grim II < > [email protected]> wrote: > >> >> >> Josh Elser said: >> >> <snip> >> >> Second, the functionality is already present by the lack of providing the >> label which you want to negate. Categorizing data into static labels tends >> to be more manageable over using many roles. While enumerating the inverse >> of a negation is possible, it is valid that the marking may be much larger >> on disk than a representation using a negation. >> >> </snip> >> >> >> >> I’m having trouble with this – perhaps I’m not thinking of it the right >> way. >> >> >> >> How would you handle mutual exclusivity? So, say I have a cell that I >> can mark M or F. If it’s M, people with M can see it. If it’s F, people >> with F can see it. But people with M&F can see it either way, and I don’t >> want that. If it’s marked F, I don’t want people with M seeing it. So >> (F&!M) makes sense to denote that. Lacking that, the only way I can see to >> implement what I want is somehow in application or business logic to make >> sure nobody gets assigned M and F at the same time…which breaks the model >> of letting Accumulo enforce visibility. >> >> >> >> Am I missing something? >> > >
