Skip to content
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

Add user property to run configurations #2055

Merged
merged 2 commits into from
Dec 5, 2024

Conversation

un-def
Copy link
Collaborator

@un-def un-def commented Dec 3, 2024

  • If not set, use the default user from the image (if it, in turn, is not set either, Docker uses root as a default value)
  • The container user is still set to root, as we need root privileges, at least to install sshd, but the runner executes the job (shell script with commands from the run configuration) as user.
  • If the user is not root, it gets its own copy of ~/.ssh/authorized_keys and ~/.ssh/environment, making it possible to ssh user@run-name (the default user is still root, that is, ssh run-name logs in as root)
  • ~/.ssh/environment is now generated by the runner, not the outer shell script (container entrypoint), and includes all the same variables as the job env (including DSTACK_* vars and vars from the env property of the run configuration)

Part-of: #1535

* If not set, use the default user from the image (if it, in turn, is
  not set either, Docker uses `root` as a default value)
* The container user is still set to `root`, as we need root privileges,
  at least to install sshd, but the runner executes the job (shell
  script with `commands` from the run configuration) as `user`.
* If the `user` is not root, it gets its own copy of
  `~/.ssh/authorized_keys` and `~/.ssh/environment`, making it possible
  to `ssh user@run-name` (the default user is still `root`, that is,
  `ssh run-name` logs in as root)
* `~/.ssh/environment` is now generated by the runner, not the outer
  shell script (container entrypoint), and includes all the same
  variables as the job env (including `DSTACK_*` vars and vars from
  the `env` property of the run configuration)

Part-of: #1535
@un-def un-def requested review from r4victor and jvstme December 3, 2024 15:08
@r4victor
Copy link
Collaborator

r4victor commented Dec 4, 2024

@un-def, could you clarify if containers running as non-root work with volumes? I'd assume that host directories would need to have appropriate permissions for the non-root user in order for volumes to work.

@un-def
Copy link
Collaborator Author

un-def commented Dec 4, 2024

@r4victor

if containers running as non-root work with volumes?

Good catch! FS permissions are addressed in 728fbca

@un-def un-def merged commit 8acd95e into master Dec 5, 2024
23 checks passed
@un-def un-def deleted the issue_1535_user_property_in_run_conf branch December 5, 2024 08:56
pranitnaik43 pushed a commit to bahaal-tech/dstack that referenced this pull request Mar 4, 2025
* If not set, use the default user from the image (if it, in turn, is
  not set either, Docker uses `root` as a default value)
* The container user is still set to `root`, as we need root privileges,
  at least to install sshd, but the runner executes the job (shell
  script with `commands` from the run configuration) as `user`.
* If the `user` is not root, it gets its own copy of
  `~/.ssh/authorized_keys` and `~/.ssh/environment`, making it possible
  to `ssh user@run-name` (the default user is still `root`, that is,
  `ssh run-name` logs in as root)
* `~/.ssh/environment` is now generated by the runner, not the outer
  shell script (container entrypoint), and includes all the same
  variables as the job env (including `DSTACK_*` vars and vars from
  the `env` property of the run configuration)

Part-of: dstackai#1535
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants