Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Behavior change in Access Controller between 0.94 and 0.98


Copy link to this message
-
Re: Behavior change in Access Controller between 0.94 and 0.98
On Thu, Apr 24, 2014 at 10:13 AM, Andrew Purtell <[EMAIL PROTECTED]>wrote:

In certain cases... (see below)
AFAIK most commercial databases don't offer the "hidden visibility" access
control differently than "access denied". That is to say, you may deny
access to a table, but in that case you get an error with any access to the
table rather than an empty result.

In our case we're probably leaking table size as well -- a scan with no key
range attached should take time proportional to the amount of data in the
table, even if you have no access. In commercial DBs I would be surprised
if a user can get these types of estimates for a table they're disallowed
from.

Right. If I have a multitenant system and I deny you access, I wouldn't
except you to be able to perform these kinds of attacks.

I'm a bit of an outsider (haven't followed the implementation of the
security features or why the design choices were made), but from the
"outsider" perspective, I would have guessed that the table-level ACLs
would have two different permissions: READ (default VISIBLE) and READ
(default INVISIBLE). If a user has the former, then they can see all cells
that aren't explicitly made invisible to them, and if the user has the
latter, they can't see any cells unless made explicitly visible. But if
they have neither type of READ permission on the table level, then they
shouldn't be able to access the table at all.

This will also come into play once we do a better job of safeguarding META.
AFAIK today a user can scan META and see the row keys for region boundaries
regardless of their access to those tables. This seems like the kind of
thing that you'd need to allow for a user who has READ (even if they have
default invisible), but you wouldn't want to allow for an arbitrary user on
the cluster.

-Todd

Todd Lipcon
Software Engineer, Cloudera