The problem I see with adding "write" visibilities along with "read" ones is that Accumulo writes "blind", without checking whether or not a cell of that type or set of labels exists. I've had it told to me in the past that this was a deliberate design decision taken to keep rates of ingest up.
So, if that's true, I don't think you could easily have "write" visibilities on a cell-by-cell basis. Having them per-table, though, seems very doable, and perhaps a lot more in-line with what people would be using such functionality for in the first place. Also, on the main topic of adding "NOT", consider my own small vote against. I think having all positive statements cuts down on the kind of reasoning a security person has to do with the overall system. I realize that there are some exclusive-OR type scenarios that are not easily accomplishable within the label language itself, but I think John's point that you could have logic in the Authorizor to cover those kinds of situations makes a lot of sense. >From an instinctive level, I view getting a visibility label as expanding the view you have across the data. Adding a NOT operator means that gaining a label for your user could be contracting your view, or could be not, depending on how the logic of the label expressions was constructed. I'd rather reason in one direction. Maybe that takes some education for users. On Mon, Mar 10, 2014 at 1:14 PM, Josh Elser <[email protected]> wrote: > > > >>>> > >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. >> >> > Another snippet from HBase writeups that caught my eye was the idea of > supporting both read and write visibilities. What we have right now is > read, with a bit of write visibilities (using the VisibilityConstraint). > The downside is that you can't let someone read data without writing to it. > > That might be something else to consider as I can see it being a common > use-case. (although it might merit its own line of work completely) > -- *Michael Allen* Security Architect | Sqrrl-----------------------------------130 Prospect Street | Cambridge, MA 02139415.699.0106 | www.sqrrl.com ----------------------------------- The information contained in this communication may be confidential, subject to legal privilege, or otherwise protected from disclosure, and is intended solely for the use of the intended recipient(s). If you are not the intended recipient of this communication, please destroy all copies in your possession, notify the sender that you have received this communication in error, and note that any review or dissemination of, or the taking of any action in reliance on, this communication is expressly prohibited. Please note that sqrrl data, INC. reserves the right to intercept, monitor, and retain e-mail messages to and from its systems as permitted by applicable law.
