Does this leave us open to leaking row existence due to timing differences?
For example, imagine you had a table where I happened to know (eg from reading your design docs on the wiki) that the key is made up of social security numbers. If I wanted to come up with a list of valid SSNs, I could issue GETs against your table. If I issue a GET for an invalid SSN, the response will come back on average quite a bit faster than if I issued a GET for a valid SSN (since the invalid SSN would be filtered by blooms where the valid one would not). -Todd On Thu, Apr 24, 2014 at 9:49 AM, Andrew Purtell <apurt...@apache.org> wrote: > This is an intended change that was done as part of introducing cell ACLs. > Otherwise we can't support use cases where the user has no authorization on > the table or CF level but cell ACLs grant exceptional access. It also > brings the AccessController behavior in line with the new > VisibilityController - cells which the user are not authorized to see are > invisible in both settings. > > Enis recently brought up the same issue, let me copy that here: > > >>> > > Subject: Get / Scan without table ACLs no longer throws > AccessDeniedException > > I was a bit surprised to find out about the case where there is a > behavioral change in trying to read from tables that the user do not have > table/cf level permission. > [...] > Also this behavioral change is applicable to the audit log as well, we no > longer mark the access granted / denied requests for gets and scans in the > audit log which is concerning. > > From the lsat paragraph in > https://blogs.apache.org/hbase/entry/hbase_cell_security, Andrew states > that there are two modes now, check cell first or not > (Query.setACLStrategy()). > > However, my understanding was that the default behavior should check table > first, and then not do the scan at all if that is denied. From the code > TableAuthManager.authorize(), it does not look to be the case. My questions > are: > 1) This is a behavioral change, and changes the default behavior as well > regardless of whether cell level security is used or not. Should we revert > back to the original behavior? > 2) Even if we do not revert, should we record get / scans in the audit log > ? > 3) Are we targeting two use cases (a) user do not have table level auth, > but selectively have cell level access, and (b) user do have table level > auth but selectively NOT have cell level access? For these two use cases, > should the strategy be a table level property rather than an per-op > property ? > > <<< > > To which I replied: > > >>> > > The answer is #3. > > It could be made a table level property. > > > Also this behavioral change is applicable to the audit log as well, we no > longer mark the access granted / denied requests for gets and scans in the > audit log which is concerning. > > This is some kind of logic bug or oversight, please file a jira. > > <<< > > So if the consensus is this is too surprising or unwanted, then we can > without much difficulty make the new behavior configurable on a per table > basis and have the default be the new behavior, with a release note and > paragraph in the security guide explaining how to reintroduce the old > behavior. I think that covers the bases. > > > > On Thu, Apr 24, 2014 at 12:35 AM, Vandana Ayyalasomayajula < > avand...@yahoo-inc.com> wrote: > > > Hi All, > > > > We have seen a behavior change in the manner AccessController blocks > > unauthorized users between 0.94 and 0.98. > > In 0.98, if an unauthorized user tried to perform GET, SCAN empty > results > > are returned, whereas the same operations > > in 0.94 used to throw access denied exceptions. > > > > Is this a behavior change or a bug in 0.98 ? It would be of great help if > > someone could point me to any jira which has discussions related to > > these changes. > > > > Thanks > > Vandana > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) > -- Todd Lipcon Software Engineer, Cloudera
