Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 15 May 2015 22:37:01 +0000 (UTC)
From: "Mikhail Antonov (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12785759.1427334903000.132042.1431729421379@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=14546304#comment-14546304 ] 

Mikhail Antonov commented on HBASE-13336:
-----------------------------------------

Looks good! A few nits:

 - getReservedColumnIfMeta - the naming suggested we expect to chech meta table, but we actually check ACL and labels tables? Would it be more consistent to name like getReservedColumnForSystemTable or so?
 - just to note that in HBASE-13375 it's proposed to eliminate multiple isSystemOrSuperUser() calls scattered over the codebase and move it to User class instead. Separate checkSystemUser() is proposed as the one throwing an exception vs. returning boolean. Just a nit though.
 - in preDisableTable do we need both log and ACE to be thrown? ACE doesn't get logged?


> 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: Srikanth Srungarapu
>             Fix For: 2.0.0, 0.98.13, 1.2.0
>
>         Attachments: HBASE-13336.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)