Skip to content

Improve docs for FileSystemAccessControl impersonation rule #10908

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.

Sign up for GitHub

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

Merged
kokosing merged 2 commits into from
Feb 3, 2022
Merged

Improve docs for FileSystemAccessControl impersonation rule #10908

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
cc5aa0b
Fix duplicate spaces in docs for FileSystemAccessControl
sbernauer Feb 2, 2022
ff22416
Improve docs for FileSystemAccessControl impersonation rule
sbernauer Feb 2, 2022
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
14 changes: 8 additions & 6 deletions docs/src/main/sphinx/security/file-system-access-control.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -364,29 +364,31 @@ use the following rules:
Impersonation rules
Comment thread
sbernauer marked this conversation as resolved.
Outdated
-------------------

These rules control the ability of a user to impersonate another user. In
These rules control the ability of a user to impersonate another user. In
some environments it is desirable for an administrator (or managed system) to
run queries on behalf of other users. In these cases, the administrator
run queries on behalf of other users. In these cases, the administrator
authenticates using their credentials, and then submits a query as a different
user. When the user context is changed, Trino will verify the administrator
user. When the user context is changed, Trino will verify the administrator
is authorized to run queries as the target user.

When these rules are present, the authorization is based on the first matching rule,
processed from top to bottom. If no rules match, the authorization is denied.
If impersonation rules are not present but the legacy principal rules are specified,
it is assumed impersonation access control is being handled by the principal rules,
so impersonation is allowed. If neither impersonation nor principal rules are
so impersonation is allowed. If neither impersonation nor principal rules are
defined, impersonation is not allowed.

Each impersonation rule is composed of the following fields:

* ``original_user`` (optional): regex to match against the user requesting the impersonation. Defaults to ``.*``.
* ``original_role`` (optional): regex to match against role names of the requesting impersonation. Defaults to ``.*``.
* ``new_user`` (required): regex to match against the user that will be impersonated.
* ``allow`` (optional): boolean indicating if the authentication should be allowed.
* ``allow`` (optional): boolean indicating if the authentication should be allowed. Defaults to ``true``.

The impersonation rules are a bit different than the other rules: The attribute ``new_user`` is required to not accidentally prevent more access than intended. Doing so it was possible to make the attribute ``allow`` optional.

The following example allows the ``admin`` role, to impersonate any user, except
for ``bob``. It also allows any user to impersonate the ``test`` user:
for ``bob``. It also allows any user to impersonate the ``test`` user:

.. literalinclude:: user-impersonation.json
:language: json
Expand Down