Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A325E1060A for ; Mon, 20 Jan 2014 08:21:23 +0000 (UTC) Received: (qmail 13053 invoked by uid 500); 20 Jan 2014 08:21:22 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 13014 invoked by uid 500); 20 Jan 2014 08:21:21 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 13000 invoked by uid 99); 20 Jan 2014 08:21:20 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Jan 2014 08:21:20 +0000 Date: Mon, 20 Jan 2014 08:21:20 +0000 (UTC) From: "Anoop Sam John (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (HBASE-10322) Strip tags from KV while sending back to client on reads 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-10322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876241#comment-13876241 ] Anoop Sam John edited comment on HBASE-10322 at 1/20/14 8:20 AM: ----------------------------------------------------------------- Sorry for the confusion Lars The final idea is that only super user can view tags. But the impl raised some issues and we decided that we will not handle at this time. As of now for 0.98.0 we will make tags as serevr only thing. No user, even super user, will be able to retrieve tags to client side. Am I making it clear now? bq.Can tackle Export/Copytable/etc later Yes for use cases of Export/Copytable we thought tags should be accessible for clients also. Then thougt might be this can be controlled via user and we can ask Export to be executed by a super user. Then only tags will get exported. Even all the KVs can be surely scanned back only when the super user is executing it. For some other users, some KVs for which he is not authorized with related labels, wont get read. was (Author: anoop.hbase): Sorry for the confusion Lars The final idea is that only super user can view tags. But the impl raised some issues and we decided that we will not handle at this time. As of now for 0.98.0 we will make tags as serevr only thing. No user, even super user, will be able to retrieve tags to client side. Am I making it clear now? > Strip tags from KV while sending back to client on reads > -------------------------------------------------------- > > Key: HBASE-10322 > URL: https://issues.apache.org/jira/browse/HBASE-10322 > Project: HBase > Issue Type: Bug > Affects Versions: 0.98.0 > Reporter: Anoop Sam John > Assignee: Anoop Sam John > Priority: Blocker > Fix For: 0.98.0, 0.99.0 > > Attachments: HBASE-10322.patch, HBASE-10322_V2.patch, HBASE-10322_codec.patch > > > Right now we have some inconsistency wrt sending back tags on read. We do this in scan when using Java client(Codec based cell block encoding). But during a Get operation or when a pure PB based Scan comes we are not sending back the tags. So any of the below fix we have to do > 1. Send back tags in missing cases also. But sending back visibility expression/ cell ACL is not correct. > 2. Don't send back tags in any case. This will a problem when a tool like ExportTool use the scan to export the table data. We will miss exporting the cell visibility/ACL. > 3. Send back tags based on some condition. It has to be per scan basis. Simplest way is pass some kind of attribute in Scan which says whether to send back tags or not. But believing some thing what scan specifies might not be correct IMO. Then comes the way of checking the user who is doing the scan. When a HBase super user doing the scan then only send back tags. So when a case comes like Export Tool's the execution should happen from a super user. > So IMO we should go with #3. > Patch coming soon. -- This message was sent by Atlassian JIRA (v6.1.5#6160)