Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 13 Oct 2015 20:45:05 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12785759.1427334903000.28444.1444769105245@Atlassian.JIRA>
In-Reply-To: <JIRA.12785759.1427334903000@Atlassian.JIRA>
References: <JIRA.12785759.1427334903000@Atlassian.JIRA>
 <JIRA.12785759.1427334903745@arcas>
Subject: [jira] [Commented] (HBASE-13336) Consistent rules for security meta
 table protections
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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)