hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: Behavior change in Access Controller between 0.94 and 0.98
Date Thu, 24 Apr 2014 17:04:26 GMT
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).


On Thu, Apr 24, 2014 at 9:49 AM, Andrew Purtell <apurtell@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 <
> avandana@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message