Hey Adam, thanks for the reply. Your caution to decouple labels from policy is certainly valuable, and much appreciated.
Here's a toy that mimics our situation. Say we are a large retail company, with lots of stores in many cities. In some sense, two stores in the same metropolitan area compete with each other for the same customers. Two stores in different areas are not really competitors. New stores are added, and existing stores are closed, but a store rarely changes cities. Let's say we want each store to see their own data, as well as data from any store that is not a competitor, but not be able to see data from competitive stores. My first thought was that the labels might be store numbers and metro areas. If store 123 located in City-State sold an item, the transaction record would carry the expression "123 | !City-State". When someone from a store does a query, the authorization labels would be the store number and city-state name. Of course, this does couple labels with the policy of determining "competitive." (Not to mention that metropolitan areas change over time.) Your "Dr. Bob" example suggests that store number alone would be a better label since it does nothing more than describe the data. The policy of identifying competitive stores would happen outside of accumulo when setting up the authorization labels for a user. That makes good sense. In this situation we could authorize every store that is outside of the metro area, but excluding stores in the same ares would be a shorter list. I will start digging into the code to add complement to the expression syntax. We are just getting started with accumulo, so it will be a while before I have a test environment setup. Thanks again for your feedback. Would love more if you have additional thoughts about any of this. Thanks, Rob On Saturday, September 1, 2012 at 9:13 PM, Adam Fuchs wrote: > Hi Rob, > > I think that a complement operator would fit naturally into Accumulo's > cell-level security mechanism. The computation wouldn't be any harder, and > the language wouldn't be significantly more complex. This would be a great > project for you to take on. Please let us know if you need any guidance on > how to approach it. > > The main reason why it isn't in there yet is because we haven't found a > direct need for it. I would caution you to avoid coupling policy too closely > with the data labels, since policy tends to change over time and isn't > necessarily directly correlated with the data being labeled. Try to keep your > labels as close to a description of the data as possible. For example, if you > are labeling my medical records, you would want to label them with something > like (AdamsMedicalRecord) rather than (DoctorBob). The policy in this domain > applied to my doctor would give Dr. Bob access to the attribute/role > "AdamsMedicalRecord". Obviously, this is a toy example, but the more policy > you can apply by changing which users have access to which labels rather than > complicating the set of labels with policy elements, the better. > > I would love to see more details on your particular attribute scheme. If you > can share those here I'm sure they would be very helpful to the community, > and then we can also comment on whether they make sense. > > Cheers, > Adam > > > On Sat, Sep 1, 2012 at 1:57 PM, Rob Nichols <[email protected]> wrote: >> What I understand from the documentation for 1.4 is that the security label >> expressions support AND, OR, and Grouping, but do not support NOT. Is this >> planned for a future release? Would there be opposition to adding >> complement to the expressions? >> >> >> Our use case involves a hierarchy of roles, and the ability to exclude one >> sub group. For concretness, say we have a label that is Group. Say we also >> have labels Group1, Group2, etc... We would occationally add sub groups, >> like Group5, Group6 after the data is populated. The authorization would >> include both "Group" and the subgroupd ("Group1"). The label expression for >> a cell might be "(Group & !Group1)". >> >> >> Should we handle this some other way? Have I misunderstood the >> documentation? Should I begin working on adding complement to the >> expressions? >> >> >> Thanks, >> Rob >
