Repository navigation
atelet: honor a container image's USER and WORKDIR #1918
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
base: main
Are you sure you want to change the base?
Changes from all commits
8f7eb07
1e0466d
fa8578d
5925173
d41a2fc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -252,6 +252,10 @@ Each entry in `containers` describes one process to run in the actor's sandbox. | |
|
|
||
| `command` and `args` resolve against the container image's `ENTRYPOINT`/`CMD` the same way [Kubernetes Pod `command`/`args`](https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/) resolve against `ENTRYPOINT`/`CMD`. If the resolved argv is empty — the image sets neither `ENTRYPOINT` nor `CMD`, and the container sets neither `command` nor `args` — `Run`/`Restore` fails. | ||
|
|
||
| The process runs as the image's `USER`, resolved as Docker does against the image's own `/etc/passwd` and `/etc/group`: a numeric `uid:gid` as is; a bare uid with its login group, or gid 0 when it has no entry; a name must have an entry or `Run`/`Restore` fails. Group memberships become supplementary groups. Ids are at most 2147483647. No `USER` means root. There is no `runAsUser` field. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could the docs also say what operators need to do after upgrading? On gVisor, golden snapshots of templates whose image sets USER or WORKDIR have to be re-taken, and data an earlier run wrote as root stays root-owned, so a process that's now non-root can read it but not change it. A short paragraph here or in the release notes would save people from debugging a failed restore.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Added to docs/upgrade.md, step 4. Wider than this: the pause image sets USER 65535 and runsc checks every container, so every gVisor snapshot from before this release breaks, not just USER/WORKDIR templates. Micro-VM snapshots resume as they were. |
||
|
|
||
| The process starts in the image's `WORKDIR`, or in `/` when the image sets none. A `WORKDIR` the image lacks is created in the actor's writable layer. There is no `workingDir` field. | ||
|
|
||
| ### Container Capabilities (`securityContext.capabilities`) | ||
|
|
||
| Each container runs with a default set of Linux capabilities — `AUDIT_WRITE`, `KILL` and `NET_BIND_SERVICE`. `securityContext.capabilities` adjusts that set, mirroring `securityContext.capabilities` on a Kubernetes Pod container. | ||
|
|
||
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.
Could this get one live run on each class before merge, with a common image that sets both, for example a node-based image with
USER 1000andWORKDIR /app? Including a durable dir and a suspend/resume would cover the case most existing templates will hit, which the unit tests can't show.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.
Will do later today! node image with USER 1000 + WORKDIR /app, durable dir, suspend/resume, both classes, on a branch stacked on #1906.