Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C92BF10081 for ; Fri, 21 Nov 2014 12:38:35 +0000 (UTC) Received: (qmail 40279 invoked by uid 500); 21 Nov 2014 12:38:34 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 40186 invoked by uid 500); 21 Nov 2014 12:38:34 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 40174 invoked by uid 99); 21 Nov 2014 12:38:34 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Nov 2014 12:38:34 +0000 Date: Fri, 21 Nov 2014 12:38:34 +0000 (UTC) From: "Anoop Sam John (JIRA)" To: dev@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Reopened] (HBASE-12346) Scan's default auths behavior under Visibility labels MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-12346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John reopened HBASE-12346: ------------------------------------ Oops!! there is a compile issue with 0.98. Will push addendum now > Scan's default auths behavior under Visibility labels > ----------------------------------------------------- > > Key: HBASE-12346 > URL: https://issues.apache.org/jira/browse/HBASE-12346 > Project: HBase > Issue Type: Bug > Components: API, security > Affects Versions: 0.98.7, 0.99.1 > Reporter: Jerry He > Assignee: Jerry He > Fix For: 2.0.0, 0.98.9, 0.99.2 > > Attachments: HBASE-12346-master-v2.patch, HBASE-12346-master-v3.patch, HBASE-12346-master-v4.patch, HBASE-12346-master-v5.patch, HBASE-12346-master.patch > > > In Visibility Labels security, a set of labels (auths) are administered and associated with a user. > A user can normally only see cell data during scan that are part of the user's label set (auths). > Scan uses setAuthorizations to indicates its wants to use the auths to access the cells. > Similarly in the shell: > {code} > scan 'table1', AUTHORIZATIONS => ['private'] > {code} > But it is a surprise to find that setAuthorizations seems to be 'mandatory' in the default visibility label security setting. Every scan needs to setAuthorizations before the scan can get any cells even the cells are under the labels the request user is part of. > The following steps will illustrate the issue: > Run as superuser. > {code} > 1. create a visibility label called 'private' > 2. create 'table1' > 3. put into 'table1' data and label the data as 'private' > 4. set_auths 'user1', 'private' > 5. grant 'user1', 'RW', 'table1' > {code} > Run as 'user1': > {code} > 1. scan 'table1' > This show no cells. > 2. scan 'table1', scan 'table1', AUTHORIZATIONS => ['private'] > This will show all the data. > {code} > I am not sure if this is expected by design or a bug. > But a more reasonable, more client application backward compatible, and less surprising default behavior should probably look like this: > A scan's default auths, if its Authorizations attributes is not set explicitly, should be all the auths the request user is administered and allowed on the server. > If scan.setAuthorizations is used, then the server further filter the auths during scan: use the input auths minus what is not in user's label set on the server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)