Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -317,7 +317,7 @@ public void checkCanAlterColumn(ConnectorSecurityContext context, SchemaTableNam
@Override
public void checkCanSetTableAuthorization(ConnectorSecurityContext context, SchemaTableName tableName, TrinoPrincipal principal)
{
if (!isAdmin(context)) {
if (!isTableOwner(context, tableName)) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is insecure. IMO it would introduce a vector attack for Trino that was removed in #10351 (it is on purpose not having all details).

It is not enough to see you can own the object, but we need to make sure that to what users we can grant it. See some thinking here #16691 (review)

Copy link
Copy Markdown
Member Author

@guyco33 guyco33 Oct 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Table owner can grant any permission to any user including the WITH GRANT OPTION, so I don't understand how changing ownership that actually add the privilege to DROP the table will add a new security risk.

Same for views. If the view security mode was set to DEFINER than all masking functions and filter rules will run on behalf of the new owner privileges, so if the new owner is blocked from viewing some specific sensitive columns, all executed queries on the view will result with masked data.
Views with INVOKER security mode are executed with the privileges of the authenticated users running the queries - so no issue here.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the new owner is blocked from viewing some specific sensitive columns

Yes. But access could be different and so it could happen that things that here not visible to original user are now accessible to that user by querying the view they created and altered (transferred ownerhsip).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But access could be different and so it could happen that things that here not visible to original user are now accessible to that user by querying the view they created and altered

You are right. The view owner can change the ownership to any privileged user, so we should allow it only for views created with INVOKER security mode

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so we should allow it only for views created with INVOKER security mode

I am not a fan of such conditions. I would prefer to have secure security model instead. However I am not sure if it is doable in hive sql-standard.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Views can be recreated by a user with proper privileges to become the new owner, so I can skip this change for views and keep it for tables only.

denySetTableAuthorization(tableName.toString(), principal);
}
}
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -945,11 +945,7 @@ public void testTableAuthorization()
"ALTER TABLE test_table_authorization.foo SET AUTHORIZATION alice",
"Cannot set authorization for table test_table_authorization.foo to USER alice");
assertUpdate(admin, "ALTER TABLE test_table_authorization.foo SET AUTHORIZATION alice");
// only admin can change the owner
assertAccessDenied(
alice,
"ALTER TABLE test_table_authorization.foo SET AUTHORIZATION alice",
"Cannot set authorization for table test_table_authorization.foo to USER alice");
assertUpdate(alice, "ALTER TABLE test_table_authorization.foo SET AUTHORIZATION alice");
// alice as new owner can now drop table
assertUpdate(alice, "DROP TABLE test_table_authorization.foo");

Expand Down Expand Up @@ -982,11 +978,10 @@ public void testTableAuthorizationForRole()
"DROP TABLE test_table_authorization_role.foo",
"Cannot drop table test_table_authorization_role.foo");
assertUpdate(admin, "ALTER TABLE test_table_authorization_role.foo SET AUTHORIZATION alice");
// Only admin can change the owner
assertAccessDenied(
assertQueryFails(
alice,
"ALTER TABLE test_table_authorization_role.foo SET AUTHORIZATION ROLE admin",
"Cannot set authorization for table test_table_authorization_role.foo to ROLE admin");
"Setting table owner type as a role is not supported");
// new owner can drop table
assertUpdate(alice, "DROP TABLE test_table_authorization_role.foo");
assertUpdate(admin, "DROP SCHEMA test_table_authorization_role");
Expand Down