You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: allow to run T containers as any user, for better volume permission handling (#253)
#### Relevant issue or PR
n/a
#### Description of changes
This enables users to execute Tesseracts as any system user, even in the
presence of volume mounts.
We achieve this in the following ways:
1. Default to running Tesseracts with the same uid as the current host
user. This fixes most permission issues right away (since everything
that's readable from the outside also becomes readable from the inside).
2. Create mount points ahead of time and ensure they have lax
permissions (rw for everyone). This makes it so named and bind-mounted
volumes are mounted with appropriate permissions, even if they're not
owned by the host user.
**Some sharp edges:**
- By default, podman mounts all volumes as owned by root, not the host
user. This needs to be overwritten via `PODMAN_USERNS=keep-id`. We
automatically add this flag if podman is detected.
- There is no reliable way to enable this option in `podman-compose`.
That is, podman users will have to use `--no-compose` for sane volume
permissions. We raise an exception if podman is used with compose +
volume mounts.
- In cases where the Tesseract user is neither `root` nor the local user
/ file owner, [files in bind-mounts need to be world-readable on the
host](https://github.com/pasteurlabs/tesseract-core/pull/253/files#diff-26bec4f76a9f4e334b738405b56d680ad704871cb6233560e9b8e703cd2becf6R494).
- Currently assumes (but not enforces) that users will use
`/tesseract/input_data` and `/tesseract/output_data` as their mount
points. I expect this to be coupled to the `--input-path` and
`--output-path` CLI args in the future (see e.g. #249).
**Main code changes:**
- Do not create a `tesseractor` user in Docker images. Instead, set
global permissions on files so containers can run as any uid / gid.
- Test [all relevant
scenarios](https://github.com/pasteurlabs/tesseract-core/pull/253/files#diff-26bec4f76a9f4e334b738405b56d680ad704871cb6233560e9b8e703cd2becf6R421).
- Add logic to detect podman and automatically inject required flags for
consistent permission handling.
- Introduce `TESSERACT_DOCKER_RUN_ARGS` config which allows users to
pass custom args to `tesseract run`. This isn't used in the final form
of this PR but I figured it's nice to have anyway.
#### Testing done
CI, + manually with Docker Desktop on OSX (where permissions are always
mapped automatically)
Copy file name to clipboardExpand all lines: docs/content/examples/building-blocks/arm64.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,4 +12,4 @@ Via `tesseract_config.yaml`, it is possible to somewhat flexibly alter the build
12
12
:language: yaml
13
13
```
14
14
15
-
Using the `custom_build_steps` field, we can run arbitrary commands on the image as if they were in a Dockerfile. We start here by temporarily setting the user to `root`, as the default user in the Tesseract build process is `tesseractor` -- which does not have root privileges -- and then switch back to the `tesseractor` user at the very end. We then run commands directly on the shell via `RUN` commands. All these steps specified in `custom_build_steps` are executed at the very end of the build process, followed only by a last execution of `tesseract-runtime check` that checks that the runtime can be launched and the user-defined `tesseract_api` module can be imported.
15
+
Using the `custom_build_steps` field, we can run arbitrary commands on the image as if they were in a Dockerfile. We run commands directly on the shell via `RUN` commands. All these steps specified in `custom_build_steps` are executed at the very end of the build process, followed only by a last execution of `tesseract-runtime check` that checks that the runtime can be launched and the user-defined `tesseract_api` module can be imported.
Copy file name to clipboardExpand all lines: docs/content/using-tesseracts/advanced.md
+13-1Lines changed: 13 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Advanced usage
2
2
3
-
## File system I/O
3
+
## File aliasing
4
4
5
5
The `tesseract` command can take care of
6
6
passing data from local disk
@@ -16,6 +16,18 @@ target path:
16
16
$ tesseract run vectoradd apply --output-path /tmp/output @inputs.json
17
17
```
18
18
19
+
## Volume mounts and user permissions
20
+
21
+
When mounting a volume into a Tesseract container, default behavior depends on the Docker engine being used. Specifically, Docker Desktop, Docker Engine, and Podman have different ways of handling user permissions for mounted volumes.
22
+
23
+
Tesseract tries to ensure that the container user has the same permissions as the host user running the `tesseract` command. This is done by setting the user ID and group ID of the container user to match those of the host user.
24
+
25
+
In cases where this fails or is not desired, you can explicitly set the user ID and group ID of the container user using the `--user` argument. This allows you to specify a different user or group for the container, which can be useful for ensuring proper permissions when accessing mounted volumes.
26
+
27
+
```{warning}
28
+
In cases where the Tesseract user is neither `root` nor the local user / file owner, you may encounter permission issues when accessing files in mounted volumes. To resolve this, ensure that the user ID and group ID are set correctly using the `--user` argument, or modify the permissions of files to be readable by any user.
29
+
```
30
+
19
31
## Passing environment variables to Tesseract containers
20
32
21
33
Through the optional `--env` argument, you can pass environment variables to Tesseracts.
0 commit comments