You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "keith-turner (via GitHub)" <gi...@apache.org> on 2023/09/25 22:39:16 UTC
[GitHub] [accumulo-access] keith-turner opened a new pull request, #15: improves project documentation
keith-turner opened a new pull request, #15:
URL: https://github.com/apache/accumulo-access/pull/15
(no comment)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo-access] ctubbsii commented on a diff in pull request #15: improves project documentation
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on code in PR #15:
URL: https://github.com/apache/accumulo-access/pull/15#discussion_r1339521118
##########
src/main/java/org/apache/accumulo/access/AccessExpression.java:
##########
@@ -63,7 +57,13 @@ public interface AccessExpression {
String getExpression();
/**
- * TODO give examples
+ * Deduplicate, sort, and flatten expressions.
+ *
+ * <p>As an example of flattening, the expression {@code A&(B&C)} can be flattened to {@code A&B&C}.
+ *
+ * <p>As an example of sorting, the expression {@code (Z&Y)|(C&B)} can be sorted to {@code (B&C)|(Y&Z)}
Review Comment:
So, I guess I'm suggesting that ColumnVisibility drop that feature as well. There many ways to normalize, and the way we did it is pretty arbitrary. Having it there at all implies there's some particular benefit to that normalization over other possible ways of doing it, and I'm not sure it makes sense to include it as a feature at all.
The reason I'm thinking about this is since this is a new library, I wouldn't want it to start out already bloated with excess features. I think this is one that isn't really needed, and omitting it could prevent a future barrage of requests to bloat it in future, with requests like "Can you add normalization that does X, Y, and Z?". If we want to add any kind of normalization feature, we could try to add a pluggable interface for a "normalizer", so if users wanted to normalize, they could do so, without bloating the library with all the different ways one might want to do it. But for now, I don't think we need to add any kind of normalization.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo-access] dlmarion commented on a diff in pull request #15: improves project documentation
Posted by "dlmarion (via GitHub)" <gi...@apache.org>.
dlmarion commented on code in PR #15:
URL: https://github.com/apache/accumulo-access/pull/15#discussion_r1336981885
##########
src/main/java/org/apache/accumulo/access/AccessEvaluator.java:
##########
@@ -22,8 +22,7 @@
/**
* <p>
- * An implementation of the Accumulo visibility standard as specified in this document (TODO write
- * the document based on current Accumulo implementation and post somewhere).
+ * Use to decide if an entity with one more sets of authorizations can access zero or more access expression.
Review Comment:
```suggestion
* Used to decide if an entity with one more sets of authorizations can access zero or more access expression.
```
##########
SPECIFICATION.md:
##########
@@ -66,47 +86,47 @@ boolean algebra.
* The symbol `|` in an access expression represents [logical disjunction][5]
which is represented in a boolean algebra as `∨`.
-When evaluating an access expression set existence checks are done against a
-subjects set of authorizations. The following is an algorithm for evaluation an
+When evaluating an access expression set existence checks are done against an
+entities set of authorizations. The following is an algorithm for evaluation an
access expression.
1. For each access-token in an access expression check if it exists in the
- subjects set of authorizations. Replace the access-token with `true` if it
+ entities set of authorizations. Replace the access-token with `true` if it
exists in the set and `false` otherwise.
2. Evaluate the expression using boolean algebra and only if its true can the
- subject access the data labeled with the access expression.
+ entity access the data labeled with the access expression.
The following is an example of evaluating the access expression
-`RED&(BLUE|GREEN)` using boolean algebra for a subject with the authorization
+`RED&(BLUE|GREEN)` using boolean algebra for a entity with the authorization
Review Comment:
```suggestion
`RED&(BLUE|GREEN)` using boolean algebra for an entity with the authorization
```
##########
src/main/java/org/apache/accumulo/access/AccessExpression.java:
##########
@@ -63,7 +57,13 @@ public interface AccessExpression {
String getExpression();
/**
- * TODO give examples
+ * Deduplicate, sort, and flatten expressions.
+ *
+ * <p>As an example of flattening, the expression {@code A&(B&C)} can be flattened to {@code A&B&C}.
+ *
+ * <p>As an example of sorting, the expression {@code (Z&Y)|(C&B)} can be sorted to {@code (B&C)|(Y&Z)}
Review Comment:
Do we want to cover the case where a user may not want to sort? For example, if they have an access expression `B|A`, and where `B` is an Authorization with a higher occurrence in their user base, they may not want to sort. This also assumes that evaluation will short-circuit on a top-level `OR` when the left-side is `true`.
##########
SPECIFICATION.md:
##########
@@ -66,47 +86,47 @@ boolean algebra.
* The symbol `|` in an access expression represents [logical disjunction][5]
which is represented in a boolean algebra as `∨`.
-When evaluating an access expression set existence checks are done against a
-subjects set of authorizations. The following is an algorithm for evaluation an
+When evaluating an access expression set existence checks are done against an
+entities set of authorizations. The following is an algorithm for evaluation an
access expression.
1. For each access-token in an access expression check if it exists in the
- subjects set of authorizations. Replace the access-token with `true` if it
+ entities set of authorizations. Replace the access-token with `true` if it
exists in the set and `false` otherwise.
2. Evaluate the expression using boolean algebra and only if its true can the
- subject access the data labeled with the access expression.
+ entity access the data labeled with the access expression.
The following is an example of evaluating the access expression
-`RED&(BLUE|GREEN)` using boolean algebra for a subject with the authorization
+`RED&(BLUE|GREEN)` using boolean algebra for a entity with the authorization
set `{RED,GREEN}`. In the example below `RED ∈ {RED,GREEN}` translates to does
`RED` exist in the set `{RED,GREEN}` which it does, so it is true.
1. RED ∈ {RED,GREEN} ∧ ( BLUE ∈ {RED,GREEN} ∨ GREEN ∈ {RED,GREEN} )
2. true ∧ ( false ∨ true )
-Since `true ∧ ( false ∨ true )` is true then the subject with authorizations
+Since `true ∧ ( false ∨ true )` is true then the entity with authorizations
`{RED,GREEN}` can access data labeled with the access expression
`RED&(BLUE|GREEN)`. The access expression `(RED&BLUE)|(GREEN&PINK)` is an
-example of an access expression that is false for a subject with authorizations
+example of an access expression that is false for a entity with authorizations
Review Comment:
```suggestion
example of an access expression that is false for an entity with authorizations
```
##########
SPECIFICATION.md:
##########
@@ -66,47 +86,47 @@ boolean algebra.
* The symbol `|` in an access expression represents [logical disjunction][5]
which is represented in a boolean algebra as `∨`.
-When evaluating an access expression set existence checks are done against a
-subjects set of authorizations. The following is an algorithm for evaluation an
+When evaluating an access expression set existence checks are done against an
+entities set of authorizations. The following is an algorithm for evaluation an
access expression.
1. For each access-token in an access expression check if it exists in the
- subjects set of authorizations. Replace the access-token with `true` if it
+ entities set of authorizations. Replace the access-token with `true` if it
exists in the set and `false` otherwise.
2. Evaluate the expression using boolean algebra and only if its true can the
- subject access the data labeled with the access expression.
+ entity access the data labeled with the access expression.
The following is an example of evaluating the access expression
-`RED&(BLUE|GREEN)` using boolean algebra for a subject with the authorization
+`RED&(BLUE|GREEN)` using boolean algebra for a entity with the authorization
set `{RED,GREEN}`. In the example below `RED ∈ {RED,GREEN}` translates to does
`RED` exist in the set `{RED,GREEN}` which it does, so it is true.
1. RED ∈ {RED,GREEN} ∧ ( BLUE ∈ {RED,GREEN} ∨ GREEN ∈ {RED,GREEN} )
2. true ∧ ( false ∨ true )
-Since `true ∧ ( false ∨ true )` is true then the subject with authorizations
+Since `true ∧ ( false ∨ true )` is true then the entity with authorizations
`{RED,GREEN}` can access data labeled with the access expression
`RED&(BLUE|GREEN)`. The access expression `(RED&BLUE)|(GREEN&PINK)` is an
-example of an access expression that is false for a subject with authorizations
+example of an access expression that is false for a entity with authorizations
`{RED,GREEN}` and it would look like the following using boolean algebra.
1. ( RED ∈ {RED,GREEN} ∧ BLUE ∈ {RED,GREEN} ) ∨ ( GREEN ∈ {RED,GREEN} ∧ PINK ∈
{RED,GREEN} )
2. ( true ∧ false ) ∨ ( true ∧ false )
An empty access expression always evaluates to true and this is only thing a
-subject with the empty set of authorizations can access.
+entity with the empty set of authorizations can access.
## Escaping
Access tokens can only contain alpha numeric characters or the characters
`_`,`-`,`.`,`:`, or `/` unless quoted using `"`. Within quotes the characters
`"` and `\` must escaped by prefixing with `\`. For example to use `abc\xyz` as
an access-token it would need to be quoted and escaped like `"abc\\xyz"`. When
-checking if an access-token exists in the subjects authorizations set it must
+checking if an access-token exists in the entities authorizations set it must
be unquoted and unescaped.
-Evaluating `"abc!12"&"abc\\xyz"&GHI`for a subject with authorizations
+Evaluating `"abc!12"&"abc\\xyz"&GHI`for a entity with authorizations
Review Comment:
```suggestion
Evaluating `"abc!12"&"abc\\xyz"&GHI`for an entity with authorizations
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo-access] keith-turner commented on a diff in pull request #15: improves project documentation
Posted by "keith-turner (via GitHub)" <gi...@apache.org>.
keith-turner commented on code in PR #15:
URL: https://github.com/apache/accumulo-access/pull/15#discussion_r1337931869
##########
src/main/java/org/apache/accumulo/access/AccessExpression.java:
##########
@@ -63,7 +57,13 @@ public interface AccessExpression {
String getExpression();
/**
- * TODO give examples
+ * Deduplicate, sort, and flatten expressions.
+ *
+ * <p>As an example of flattening, the expression {@code A&(B&C)} can be flattened to {@code A&B&C}.
+ *
+ * <p>As an example of sorting, the expression {@code (Z&Y)|(C&B)} can be sorted to {@code (B&C)|(Y&Z)}
Review Comment:
> I'm wondering if we should avoid doing any kind of normalization, and just keep things exactly as the user has specified when it was constructed.
Normalization only happens when explicitly requested, it does not happen every time an access expression is created. So by default the expression will be kept exactly as it was provided. This method was added so ColumnVisibility could call it which offers this functionality where its also optional.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo-access] keith-turner commented on a diff in pull request #15: improves project documentation
Posted by "keith-turner (via GitHub)" <gi...@apache.org>.
keith-turner commented on code in PR #15:
URL: https://github.com/apache/accumulo-access/pull/15#discussion_r1337415876
##########
src/main/java/org/apache/accumulo/access/AccessExpression.java:
##########
@@ -63,7 +57,13 @@ public interface AccessExpression {
String getExpression();
/**
- * TODO give examples
+ * Deduplicate, sort, and flatten expressions.
+ *
+ * <p>As an example of flattening, the expression {@code A&(B&C)} can be flattened to {@code A&B&C}.
+ *
+ * <p>As an example of sorting, the expression {@code (Z&Y)|(C&B)} can be sorted to {@code (B&C)|(Y&Z)}
Review Comment:
> Do we want to cover the case where a user may not want to sort?
Possibly, but I would wait and see what is requested. If someone is crafting their expressions with such care they may have other surprising requirements that they would want from an expression transformation. For example instead of not sorting, maybe someone would want to pass a custom comparator. Or maybe someone's transformation request is so complex that we just point them to the antlr example instead of trying to implement it in the base library.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo-access] keith-turner merged pull request #15: improves project documentation
Posted by "keith-turner (via GitHub)" <gi...@apache.org>.
keith-turner merged PR #15:
URL: https://github.com/apache/accumulo-access/pull/15
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo-access] ctubbsii commented on a diff in pull request #15: improves project documentation
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on code in PR #15:
URL: https://github.com/apache/accumulo-access/pull/15#discussion_r1337775275
##########
src/main/java/org/apache/accumulo/access/AccessExpression.java:
##########
@@ -63,7 +57,13 @@ public interface AccessExpression {
String getExpression();
/**
- * TODO give examples
+ * Deduplicate, sort, and flatten expressions.
+ *
+ * <p>As an example of flattening, the expression {@code A&(B&C)} can be flattened to {@code A&B&C}.
+ *
+ * <p>As an example of sorting, the expression {@code (Z&Y)|(C&B)} can be sorted to {@code (B&C)|(Y&Z)}
Review Comment:
I'm wondering if we should avoid doing any kind of normalization, and just keep things exactly as the user has specified when it was constructed. It'd be up to the user to optimize or normalize themselves, if they need to. We don't need to have any kind of normalization in the spec.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org