-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always create new identity for view owner #15111
Conversation
5426e6a
to
2d57b0f
Compare
2d57b0f
to
4cd7187
Compare
identity = Identity.from(owner.get()) | ||
.withGroups(groupProvider.getGroups(owner.get().getUser())) | ||
.build(); | ||
viewAccessControl = new ViewAccessControl(accessControl, session.getIdentity()); | ||
if (owner.get().getUser().equals(session.getIdentity().getUser())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks to this if
view owner does not require GRANT OPTION
to access base tables. Do you think I should update the comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, "don't restrict owner's access" is kinda vague... And this rule that view owner does not require grant option is kinda obscure. Probably a good idea to clarify.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that "Always create new identity for view owner" conveys no meaning. It's not terrible -- a person reading commit log may understand that the title doesn't hint and the change meaning and will proably read the full message. but we could do better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I improved commit message too.
4cd7187
to
bee9b03
Compare
core/trino-main/src/test/java/io/trino/server/TestHttpRequestSessionContextFactory.java
Show resolved
Hide resolved
core/trino-main/src/main/java/io/trino/server/testing/TestingSystemSecurityMetadata.java
Outdated
Show resolved
Hide resolved
identity = Identity.from(owner.get()) | ||
.withGroups(groupProvider.getGroups(owner.get().getUser())) | ||
.build(); | ||
viewAccessControl = new ViewAccessControl(accessControl, session.getIdentity()); | ||
if (owner.get().getUser().equals(session.getIdentity().getUser())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that "Always create new identity for view owner" conveys no meaning. It's not terrible -- a person reading commit log may understand that the title doesn't hint and the change meaning and will proably read the full message. but we could do better.
.setAdditionalModule(binder -> { | ||
newOptionalBinder(binder, SystemSecurityMetadata.class) | ||
.setBinding() | ||
.to(TestingSystemSecurityMetadata.class) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this change meaning of all pre-existing tests in this class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. Other tests rely on TestingAccessControlManager
which controls testing privileges.
Also notice that by default we were using DisabledSystemSecurityMetadata
which was returning empty for getViewRunAsIdentity
. This works the same way with TestingSystemSecurityMetadata
as nobody calls setViewOwner
directly.
testing/trino-tests/src/test/java/io/trino/security/TestAccessControl.java
Outdated
Show resolved
Hide resolved
// TestingAccessControlManager works by denying accesses, so: | ||
// * viewOwnerSession does not have deniedrole enabled | ||
// * the owner has a role grant to deniedrole | ||
// we deny access to deniedrole, so: | ||
// * even though viewOwnerSession would be allowed, | ||
// * the session created for view owner will be denied |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we testing TestingAccessControlManager? I..e. testing the testing code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No really. But we need mocks to work as real implementation. I will improve a comment. It is a bit scary and moves focus towards testing code.
testing/trino-tests/src/test/java/io/trino/security/TestAccessControl.java
Outdated
Show resolved
Hide resolved
@@ -4522,7 +4522,7 @@ private void analyzeRowFilter(String currentIdentity, Table table, QualifiedObje | |||
ExpressionAnalysis expressionAnalysis; | |||
try { | |||
expressionAnalysis = ExpressionAnalyzer.analyzeExpression( | |||
createViewSession(filter.getCatalog(), filter.getSchema(), Identity.forUser(filter.getIdentity()).build(), session.getPath()), // TODO: path should be included in row filter | |||
createViewSession(filter.getCatalog(), filter.getSchema(), Identity.ofUser(filter.getIdentity()), session.getPath()), // TODO: path should be included in row filter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Let's maybe move it to separate PR?
core/trino-main/src/test/java/io/trino/server/TestHttpRequestSessionContextFactory.java
Show resolved
Hide resolved
core/trino-spi/src/test/java/io/trino/spi/security/TestIdentity.java
Outdated
Show resolved
Hide resolved
bee9b03
to
11984c7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed comments. Please take a look.
core/trino-main/src/main/java/io/trino/server/testing/TestingSystemSecurityMetadata.java
Outdated
Show resolved
Hide resolved
identity = Identity.from(owner.get()) | ||
.withGroups(groupProvider.getGroups(owner.get().getUser())) | ||
.build(); | ||
viewAccessControl = new ViewAccessControl(accessControl, session.getIdentity()); | ||
if (owner.get().getUser().equals(session.getIdentity().getUser())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I improved commit message too.
.setAdditionalModule(binder -> { | ||
newOptionalBinder(binder, SystemSecurityMetadata.class) | ||
.setBinding() | ||
.to(TestingSystemSecurityMetadata.class) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. Other tests rely on TestingAccessControlManager
which controls testing privileges.
Also notice that by default we were using DisabledSystemSecurityMetadata
which was returning empty for getViewRunAsIdentity
. This works the same way with TestingSystemSecurityMetadata
as nobody calls setViewOwner
directly.
// TestingAccessControlManager works by denying accesses, so: | ||
// * viewOwnerSession does not have deniedrole enabled | ||
// * the owner has a role grant to deniedrole | ||
// we deny access to deniedrole, so: | ||
// * even though viewOwnerSession would be allowed, | ||
// * the session created for view owner will be denied |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No really. But we need mocks to work as real implementation. I will improve a comment. It is a bit scary and moves focus towards testing code.
testing/trino-tests/src/test/java/io/trino/security/TestAccessControl.java
Outdated
Show resolved
Hide resolved
core/trino-main/src/test/java/io/trino/server/TestHttpRequestSessionContextFactory.java
Show resolved
Hide resolved
3743ed5
to
f39a776
Compare
testing/trino-tests/src/test/java/io/trino/server/testing/TestSystemSecurityMetadata.java
Outdated
Show resolved
Hide resolved
The rationale is that, in addition to the user name, all of these can affect access control decisions for an `Identity`, so they should be considered distinct if any of those attributes differ. The `StatementAnalyzer`, during the analysis stage, collects all table references along with their corresponding access controls and identities. At the end of the analysis, this is used to do the access checks. They are collected in a `Map`, where the key is the pair of access control and `Identity`, so that we deduplicate the necessary checks. But for this deduplication to work properly, `Identity` instances that result in different accesses should be considered distinct. Remove obsolete AccessControlUtil.FullIdentityEquality. Now `Identity` itself has full identity.
The test is single-threaded so using `executeExclusively` is not much beneficial. Removing usage of that method makes a test way simplified.
Session user may have not always all roles enabled. Reusing session when session user equals view owner may end up with different access. Notice, that we can still reuse access control and not use dedicated view access control. This is because view owner does not need to grant access to itself, having access is just enough. I mean view owner does not requires privileges with GRANT OPTION to access objects used in the view. Co-authored-by: Grzegorz Kokosiński <grzegorz@starburstdata.com>
f39a776
to
36934db
Compare
return queries.stream() | ||
.filter(queryInfo -> { | ||
Identity queryIdentity = queryInfo.getSession().toIdentity(); | ||
return queryIdentity.getUser().equals(identity.getUser()) || allowedOwners.contains(new FullIdentityEquality(queryIdentity)); | ||
return queryIdentity.getUser().equals(identity.getUser()) || allowedOwners.contains(queryIdentity); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: previously it was a set whereas now it's just a collection so contains might be a bit slower (assuming the returned collection is not actually a set ofc)
Does this need a release note? @kokosing |
I don't think so. |
No description provided.