[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970210#comment-13970210 ] Hudson commented on HBASE-10823: FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #263 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/263/]) HBASE-10823 Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs (apurtell: rev 1587653) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestCellACLWithMultipleVersions.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestCellACLs.java Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970245#comment-13970245 ] Hudson commented on HBASE-10823: FAILURE: Integrated in HBase-TRUNK #5087 (See [https://builds.apache.org/job/HBase-TRUNK/5087/]) HBASE-10823 Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs (apurtell: rev 1587648) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestCellACLWithMultipleVersions.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestCellACLs.java Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970285#comment-13970285 ] Hudson commented on HBASE-10823: SUCCESS: Integrated in HBase-0.98 #279 (See [https://builds.apache.org/job/HBase-0.98/279/]) HBASE-10823 Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs (apurtell: rev 1587653) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestCellACLWithMultipleVersions.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestCellACLs.java Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969125#comment-13969125 ] Andrew Purtell commented on HBASE-10823: Ok, unless there is further comment I will commit the patch on this issue and we can follow up on HBASE-10970 after that JIRA is improved. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967424#comment-13967424 ] ramkrishna.s.vasudevan commented on HBASE-10823: bq.Also we have to consider exact version deletion [ deleteColumns() and deleteColumn() ] Regarding the exact version deletion pls see the comment in HBASE-10885. The exact version deletion also check for the preceeding version though the latest version allows the permission. I think we can check this once again? What you think Andy? This patch is fine with the case of future timestamps. bq.So in the acl check place also we might have to do ts based cell skip. +1. Good, interesting issue. Sorry for being late into this. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967594#comment-13967594 ] Andrew Purtell commented on HBASE-10823: bq. (Anoop) So in the acl check place also we might have to do ts based cell skip.This we can do in a follow on Jira. Also we will need all fancy test cases. Agree, this is what I meant above about We may have to resort to a custom filter ultimately. bq. (Ram) The exact version deletion also check for the preceeding version though the latest version allows the permission Agree, exact version deletion should not check earlier versions. So to proceed, seems consensus is we commit the patch on this issue and resolve it to improve existing behavior wrt future timestamps, and then carry the further work forward to a new JIRA. We can do either or both of the below two things (or other ideas?): 1. Further improve the covering permissions check in the AccessController by building a map of TimeRanges, pass this map to a custom filter, and have the custom filter select what cells are relevant for ACL checks. This is what I would like to try as the next step. 2. Add Get#addColumn and Get#addFamily methods that take a timestamp like Delete#deleteColumn and Delete#deleteFamily and add support in the query trackers. Essentially provide a mode for Get that has the exact same semantics as Delete. I have not looked into this in detail but it feels complicated. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966319#comment-13966319 ] Anoop Sam John commented on HBASE-10823: See the new test TestAccessController#testCellPermissionsWithDeleteWithTs We will need a bigger change to pass the test. I will try out a patch tonight. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966712#comment-13966712 ] Andrew Purtell commented on HBASE-10823: bq. Scan scan = new Scan(row, row) You are right, the change from Get to Scan is wrong. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966715#comment-13966715 ] Andrew Purtell commented on HBASE-10823: Before we do more work on this issue I am going to separate out and commit the unit test refactoring also done. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966733#comment-13966733 ] Andrew Purtell commented on HBASE-10823: I will commit the subtask HBASE-10963 using CTR since it's just a test refactor shortly. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966837#comment-13966837 ] Andrew Purtell commented on HBASE-10823: Good test, working on it. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966899#comment-13966899 ] Anoop Sam John commented on HBASE-10823: Me too was trying for fix Andy. :) Infact made one and the test passing with that. In that I am facing an issue with Delete object. Let me raise an issue for that. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966945#comment-13966945 ] Andrew Purtell commented on HBASE-10823: Sorry about that, but this issue is assigned to me, so... Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966943#comment-13966943 ] Andrew Purtell commented on HBASE-10823: I have a working patch Anoop. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966971#comment-13966971 ] Andrew Purtell commented on HBASE-10823: [~anoop.hbase] do you think the latest patch here is sufficient for now? Over time I think we should write more tests. One thing I worry about is I do not want to scan more than once for all cells, but we may not be able to handle all corner cases in a single scan. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[
https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967008#comment-13967008
]
Anoop Sam John commented on HBASE-10823:
Oh Sorry Andy.. I was trying to pass the new test.
bq.Anoop Sam John do you think the latest patch here is sufficient for now?
With considering the last cell's TS...!! hmm I doubt...
In the same test which I attached, we can have like
{code}
Delete d = new Delete(TEST_ROW1);
d.deleteColumns(TEST_FAMILY, TEST_Q2, 124L);
d.deleteColumns(TEST_FAMILY, TEST_Q1, 127L);
{code}
such that for Q1 we may have to check for 2 cells acl but for Q2 only 1 cell's.
Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
Key: HBASE-10823
URL: https://issues.apache.org/jira/browse/HBASE-10823
Project: HBase
Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
Fix For: 0.99.0, 0.98.2
Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch,
test.patch
Storing values with timestamps in the future is probably bad practice and can
lead to surprises. If cells with timestamps in the future have ACLs,
permissions from those ACLs will incorrectly be considered for authorizing
the pending mutation. For sure that will be surprising.
We should be able to avoid this case by resolving LATEST_TIMESTAMP to the
current server time when creating the internal scanner for finding ACLs in
the covered cell set.
Documenting a todo item from a discussion between [~anoop.hbase] and myself.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967090#comment-13967090 ] Andrew Purtell commented on HBASE-10823: bq. With considering the last cell's TS...!! No that's not it. We issue one Get to find the covered cells, and we want to put a timerange on it. Timerange does not allow discontinuities, and gets do not allow a timerange per family or family:qualifer. So we find the latest timestamp either specified by the op or one of the cells therein and go with that. I think that is fine for now. We may have to resort to a custom filter ultimately. We are making a decision about the entire Delete op, and as long as we are not allowing something we shouldn't, any usability concerns are mitigated by just issuing multiple Deletes separately. So unless objection I am going to commit this patch as better than what we have now, unless you are thinking of a logic bug that allows something we shouldn't. Then let's look at a test case for that. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967099#comment-13967099 ] Andrew Purtell commented on HBASE-10823: Another way to state the above is to get with a Get the exact set of cells as a Delete, specified by all possible forms of a Delete op, we are missing Get#addColumn and Get#addFamily methods that take a timestamp like Delete#deleteColumn and Delete#deleteFamily, but what we really want is a timerange not a timestamp. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967108#comment-13967108 ] Andrew Purtell commented on HBASE-10823: Ping [~stack] and [~mbertozzi], I know you guys have been looking around this area now and again. I think this issue is of the interesting variety. Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs Key: HBASE-10823 URL: https://issues.apache.org/jira/browse/HBASE-10823 Project: HBase Issue Type: Improvement Affects Versions: 0.98.1 Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.99.0, 0.98.2 Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch Storing values with timestamps in the future is probably bad practice and can lead to surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will incorrectly be considered for authorizing the pending mutation. For sure that will be surprising. We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server time when creating the internal scanner for finding ACLs in the covered cell set. Documenting a todo item from a discussion between [~anoop.hbase] and myself. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[
https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967378#comment-13967378
]
Anoop Sam John commented on HBASE-10823:
bq. I think that is fine for now.
Yes this is obviously better than the current state. +1 for commit this Andy.
What I was saying abt the TS , I can explain with an eg:
||cf:c1|| cf:c2||
|c1v1 (ts=100) | c2v1 (ts=100)|
|c1v2 (ts=102) | c2v2 (ts=102)|
|c1v3 (ts=104) | c2v3 (ts=104)|
Now consider a Delete
{code}
Delete d = new Delete(r1);
d.deleteColumns(cf, c1, 105);
d.deleteColumns(cf, c2, 102);
{code}
So here for the Get we will have a time range of 0 - 105. For the column cf:c1
we have to check the cell acl for all the versions v1, v2 and v3 (as the delete
will mask all versions). But for cf:c2 we have to check only 2 versions v1 and
v2. So in the acl check place also we might have to do ts based cell skip.
This we can do in a follow on Jira. Also we will need all fancy test cases.
Also we have to consider exact version deletion [ deleteColumns() and
deleteColumn() ]
Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
Key: HBASE-10823
URL: https://issues.apache.org/jira/browse/HBASE-10823
Project: HBase
Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
Fix For: 0.99.0, 0.98.2
Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch,
test.patch
Storing values with timestamps in the future is probably bad practice and can
lead to surprises. If cells with timestamps in the future have ACLs,
permissions from those ACLs will incorrectly be considered for authorizing
the pending mutation. For sure that will be surprising.
We should be able to avoid this case by resolving LATEST_TIMESTAMP to the
current server time when creating the internal scanner for finding ACLs in
the covered cell set.
Documenting a todo item from a discussion between [~anoop.hbase] and myself.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
[
https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966198#comment-13966198
]
Anoop Sam John commented on HBASE-10823:
{code}
- Get get = new Get(row);
- if (timestamp != HConstants.LATEST_TIMESTAMP)
get.setTimeStamp(timestamp);
+ Scan scan = new Scan(row);
+ if (timestamp != HConstants.LATEST_TIMESTAMP) {
+scan.setTimeRange(0, timestamp + 1);
+ } else {
{code}
This change from Get to Scan is to set a TimeRange right Andy? We create scan
with startRow alone? we need
Scan scan = new Scan(row, row) (?)
Also wrt the TS issue which I was thinking, it is bit different than this..
Let me come up with a test to demonstrate that. Will give test later today.
Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
Key: HBASE-10823
URL: https://issues.apache.org/jira/browse/HBASE-10823
Project: HBase
Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
Fix For: 0.99.0, 0.98.2
Attachments: HBASE-10823.patch
Storing values with timestamps in the future is probably bad practice and can
lead to surprises. If cells with timestamps in the future have ACLs,
permissions from those ACLs will incorrectly be considered for authorizing
the pending mutation. For sure that will be surprising.
We should be able to avoid this case by resolving LATEST_TIMESTAMP to the
current server time when creating the internal scanner for finding ACLs in
the covered cell set.
Documenting a todo item from a discussion between [~anoop.hbase] and myself.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
