Roles of original users are not persisted through SET SESSION AUTHORIZATION calls

[homar]

Roles of original users are not persisted through SET SESSION AUTHORIZATION calls which leads to failure of each subsequent queries done by impersonated user.
The reason is that each of those queries will be first checked with checkCanImpersonateUser check and each of them will fail because original user won't have any enabled roles that would allow impersonation.

Example:

1. user 'alicecallsSET SESSION AUTHORIZATION 'bob'`
2. that leads to invocation of io.trino.security.AccessControl#checkCanImpersonateUser
3. this check passes
4. then user 'bob' calls 'SHOW CATALOGS' (or any other query)
5. that leads to invocation of io.trino.security.AccessControl#checkCanImpersonateUser
6. this check fails as alice has no roles enabled

This incorrect behaviour is demonstrated in this draft PR in TestImpersonation.testImpersonate()

Basically after bob is impersonated no roles are assigned to him and thus following checkCanImpersonateUser checks fail.

[martint]

Have you looked at #2512 ? There's an extensive discussion on the semantics of SET SESSION AUTHORIZATION. I'd like to be sure that we're not undoing some intended behavior.

[kokosing]

Thanks for taking a look. I think it matches the discussion there, but there is one (bug) thing that was missed in the original discussion. See #2512 (comment)

When SET SESSION AUTHORIZATION X is executed =>

• If sessionUser is the same as authorizationUser:
  • Check for impersonation of X against existing (sessionUser, role)
    . * If so - set the header. Remove role. Next queries execute as (x, none).
• Else:
  • Check for impersonation against existing (sessionUser, none).
  • If so - set the header. Remove role. next queries execute as (x, none).

In the first call we do Check for impersonation of X against existing (sessionUser, role) and in the next it was suggested to do Check for impersonation against existing (sessionUser, none). This is incorrect as as in second request there role missing that might be important to to grant the access for impersonation. This issue is about that case.

[kokosing]

Fixed with #25371