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

ramkrishna.s.vasudevan commented on HBASE-10322:
------------------------------------------------

>>bq.CellCodecV2 is used as default. But I think there should not be any 
>>default value for this codec because of the below reason. (Default value 
>>should be value of the old config with thats default as KVCodec)
Suppose the src cluster user is upgrading to 98 (or later versions in future) 
But the peer is still in 96 .
I agree. the patch's intention was to show how we could do that config 
settings. +1
[~lhofhansl]
bq.if I can see a certain KV, should I be able to see its visibility tags?
What you say is right in the sense admin sets up proper access control say for 
User A and User A would be seeing only those KVs which has visibility labels 
that A is associated with.  But sometimes the labels can be combination of 
visibility labels seperted by &,|,!.  In that case the User A on reading the 
visibility labels would come to know about the existence of other labels.  And 
added to that, the whole idea of associating the labels and users are done by 
admin with super user privileges.  So allowing all users to view the labels in 
the KV would break it because reading the kv the User A would come to know what 
combination of labels he can pass to access the kvs to which he would not be 
authorised to.

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

Reply via email to