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

cmd/enter: honor user’s configured shell inside toolbox #1037

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

yann-soubeyrand
Copy link

No description provided.

@softwarefactory-project-zuul
Copy link

Build succeeded.

@HarryMichal HarryMichal added 3. Enhancement Improvement to an existing feature 6. Major Change May cause breakage 2. Container Realm The issue is related to what happens inside of a toolbox container 7. Needs tests The work needs new test cases added labels May 13, 2022
@HarryMichal
Copy link
Member

@yann-soubeyrand, this is marvellous! This is something I've wanted to do for Toolbx in the near future. It'll still have to wait a little bit before merging (and most definitely will mess the nearest release) but I'm quite certain this is exactly what we need. Many thanks!

doc/toolbox-sh.1.md Outdated Show resolved Hide resolved
@softwarefactory-project-zuul
Copy link

Build succeeded.

✔️ unit-test SUCCESS in 6m 56s
✔️ system-test-fedora-rawhide SUCCESS in 15m 46s
✔️ system-test-fedora-36 SUCCESS in 9m 50s
✔️ system-test-fedora-35 SUCCESS in 10m 07s
✔️ system-test-fedora-34 SUCCESS in 10m 26s

@yann-soubeyrand
Copy link
Author

Hello @HarryMichal, do you have any news about this PR?

@softwarefactory-project-zuul
Copy link

Build succeeded.

✔️ unit-test SUCCESS in 8m 14s
✔️ unit-test-migration-path-for-coreos-toolbox SUCCESS in 7m 28s
✔️ system-test-fedora-rawhide SUCCESS in 11m 04s
✔️ system-test-fedora-36 SUCCESS in 10m 26s
✔️ system-test-fedora-35 SUCCESS in 10m 43s

Copy link
Member

@debarshiray debarshiray left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this, @yann-soubeyrand !

src/cmd/sh.go Outdated Show resolved Hide resolved
doc/toolbox-create.1.md Outdated Show resolved Hide resolved
doc/toolbox-sh.1.md Outdated Show resolved Hide resolved
src/cmd/sh.go Outdated Show resolved Hide resolved
src/cmd/sh.go Outdated Show resolved Hide resolved
doc/toolbox-init-container.1.md Outdated Show resolved Hide resolved
src/cmd/create.go Outdated Show resolved Hide resolved
src/cmd/initContainer.go Outdated Show resolved Hide resolved
src/cmd/sh.go Outdated Show resolved Hide resolved
src/cmd/initContainer.go Outdated Show resolved Hide resolved
% toolbox-sh(1)

## NAME
toolbox\-sh - Launch user configured shell inside container
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are other use-cases for this: #988

It can have an impact on the name. Although, since it's an internal implementation detail we can always change the name of the command later.

@yann-soubeyrand
Copy link
Author

Hi @debarshiray,

Regarding initial shell configuration, I was wondering why we don’t let useradd use the default system configuration in /etc/default/useradd. Indeed, that seems to be the more sensible thing to do since we’d be assured the configured shell would be present (unless the container image used is really bad) and the user shouldn’t be surprised to end up with the default shell configured in the container image.

However, I didn’t understand why my first shell was always configured to /bin/sh whereas useradd configuration indicates /bin/bash as the default. It turns out that my user isn’t created by toolbox init-container but by podman due to the use of the --userns keep-id option.

I’m not sure where to go from now on. Should we try to get podman use the default shell configured in the container image? Or should we go with the mechanism to indicate that “factory reset” of the toolbox has already been done?

@softwarefactory-project-zuul
Copy link

Build failed.

unit-test FAILURE in 25m 50s
unit-test-migration-path-for-coreos-toolbox FAILURE in 3m 17s
✔️ system-test-fedora-rawhide SUCCESS in 32m 10s
✔️ system-test-fedora-36 SUCCESS in 12m 10s
✔️ system-test-fedora-35 SUCCESS in 13m 25s

@yann-soubeyrand
Copy link
Author

I’m not sure where to go from now on. Should we try to get podman use the default shell configured in the container image? Or should we go with the mechanism to indicate that “factory reset” of the toolbox has already been done?

podman seems to directly write passwd entries in /etc/passwd so I guess it won’t be possible to easily and reliably make it use the default shell of the system. We’re left with the second solution then. How do you see it? Should we put a file in /var/lib/toolbox/ inside the toolbox container to indicate that initialization has already been done?

@softwarefactory-project-zuul
Copy link

Build failed.

unit-test FAILURE in 23m 55s
unit-test-migration-path-for-coreos-toolbox FAILURE in 3m 00s
✔️ system-test-fedora-rawhide SUCCESS in 34m 11s
✔️ system-test-fedora-36 SUCCESS in 12m 07s
✔️ system-test-fedora-35 SUCCESS in 13m 32s

@yann-soubeyrand
Copy link
Author

Hi @debarshiray, I think I’ve addressed your points and I’d be glad to hear your feedback.

I’ve tried to separated the work done by toolbox init-container in two categories: the toolbox initialization phase, which should be done only once during the first container start, and the start phase, which should be done each time the container is started. I’m not sure I separated things correctly, though.

I’ve still unanswered questions in my head:

  • Will we want to use the toolbox sh command for toolbox run?
  • How does the whole thing with capsh work? I’m under the impression that capsh execs bash, which execs toolbox sh, which execs the user shell. Is it possible to simplify things? What’s the role of capsh here?

Copy link

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/358a57ec48424952905e89dcaa262950

✔️ unit-test SUCCESS in 5m 46s
✔️ unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 31s
✔️ unit-test-restricted SUCCESS in 5m 44s
system-test-fedora-rawhide FAILURE in 1h 45m 39s
system-test-fedora-40 FAILURE in 1h 45m 59s
system-test-fedora-39 FAILURE in 1h 48m 57s

@yann-soubeyrand
Copy link
Author

Hi @debarshiray, the user’s configured shell is still not honoured on Fedora 42 with ptyxis, is this PR still relevant or do you plan to address the problem differently with ptyxis?

Signed-off-by: Yann Soubeyrand <github@yann.soubeyrand.eu>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2. Container Realm The issue is related to what happens inside of a toolbox container 3. Enhancement Improvement to an existing feature 6. Major Change May cause breakage 7. Needs tests The work needs new test cases added
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants