[
https://issues.apache.org/jira/browse/HBASE-13336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955631#comment-14955631
]
Andrew Purtell edited comment on HBASE-13336 at 10/13/15 8:48 PM:
------------------------------------------------------------------
bq. As it seems to be intended in this patch (and what looks logical), we want
to have each of 2 controllers (AC and VC) to cross-check both security tables,
right?
Hmm.. I think it has to be done in core code, since neither AC nor VC should
know the internals of the other. Let's look at this instead as applying
consistent protections to meta tables in general, anything in the 'hbase:'
namespace.
- Allow adding columns, but only if superuser.
- Allow modifying column or table descriptor attributes, but only if superuser.
- Disallow column and table drops, unless the requester is a superuser.
- Disallow table disable, unless the requester is a superuser.
- Allow enable and other admin requests (flush, compaction, region move) only
if superuser.
We could add a check for superuser privilege just after the point where we call
the preXXX coprocessor hook for the respective operation, but we would want to
skip this check if the coprocessor - somehow - indicates to us an authoritative
decision was made (only the AC would be in a position to do this currently). We
don't have a provision for doing that yet. If a coprocessor didn't handle it,
we would throw an ADE if the user is not a superuser.
was (Author: apurtell):
bq. As it seems to be intended in this patch (and what looks logical), we want
to have each of 2 controllers (AC and VC) to cross-check both security tables,
right?
Hmm.. I think it has to be done in core code, since neither AC nor VC should
know the internals of the other. Let's look at this instead as applying
consistent protections to meta tables in general, anything in the 'hbase:'
namespace.
- Allow adding columns, but only if superuser. This is something core code can
check, but ideally only if an installed coprocessor (the AC) didn't handle it.
- Allow modifying column or table descriptor attributes, but only if superuser.
This is also something core code can check, but ideally only if an installed
coprocessor (the AC) didn't handle it.
- Unconditionally disallow required column and table drops. This is something
the VC and AC can handle themselves.
Unconditionally disallow table disable. If the superuser is asking, log a WARN
indicating the coprocessors must be removed from config first.
- Allow enable (a no-op hopefully) and other admin requests (flush, compaction,
region move), only if superuser. Again, this is something core code can check,
but ideally only if an installed coprocessor (the AC) didn't handle it.
We could add a check for superuser privilege just after the point where we call
the preXXX coprocessor hook for the respective operation, but we would want to
skip this check if the coprocessor - somehow - indicates to us an authoritative
decision was made. We don't have a provision for doing that yet.
> Consistent rules for security meta table protections
> ----------------------------------------------------
>
> Key: HBASE-13336
> URL: https://issues.apache.org/jira/browse/HBASE-13336
> Project: HBase
> Issue Type: Improvement
> Reporter: Andrew Purtell
> Assignee: Mikhail Antonov
> Fix For: 2.0.0, 1.3.0, 0.98.16
>
> Attachments: HBASE-13336.patch, HBASE-13336_v2.patch
>
>
> The AccessController and VisibilityController do different things regarding
> protecting their meta tables. The AC allows schema changes and disable/enable
> if the user has permission. The VC unconditionally disallows all admin
> actions. Generally, bad things will happen if these meta tables are damaged,
> disabled, or dropped. The likely outcome is random frequent (or constant)
> server side op failures with nasty stack traces. On the other hand some
> things like column family and table attribute changes can have valid use
> cases. We should have consistent and sensible rules for protecting security
> meta tables.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
