hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13336) Consistent rules for security meta table protections
Date Tue, 13 Oct 2015 20:45:05 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955631#comment-14955631
] 

Andrew Purtell commented on HBASE-13336:
----------------------------------------

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)

Mime
View raw message