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

Arbitrary user ID is comming $HOME #86

Merged
merged 4 commits into from
Dec 11, 2020

Conversation

jpopelka
Copy link
Member

@jpopelka jpopelka commented Nov 23, 2020

(hopefully) Fixes #85

Trying in 2 terminals

$ docker build && docker run -ti --rm -u 123456 usercont/sandcastle
$ docker ps && docker exec -ti -u 123456 <container name> npm install bower
+ bower@1.8.8
added 1 package from 1 contributor and audited 1 package in 3.44s

@softwarefactory-project-zuul

This comment has been minimized.

Copy link
Member

@TomasTomecek TomasTomecek left a comment

Choose a reason for hiding this comment

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

sadly all the nested tests are failing :/ are you working for you locally?

Dockerfile Outdated
HOME=/home/sandcastle

# npm needs to access ~/.npm and ~/.config
RUN mkdir --mode 0776 ${HOME}
Copy link
Member

Choose a reason for hiding this comment

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

this should ideally be owned by sandcastle user

Copy link
Member Author

Choose a reason for hiding this comment

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

there's no such user at the time of building the image

@jpopelka jpopelka force-pushed the npm-home branch 6 times, most recently from 5d0f1a1 to e773a2a Compare November 24, 2020 15:44
@softwarefactory-project-zuul
Copy link
Contributor

Build failed.

@jpopelka
Copy link
Member Author

sadly all the nested tests are failing :/ are you working for you locally?

nope and moreover, they fail from some different cause locally
(ERROR: not found: /home/sandcastle/tests/e2e/test_ironman.py::test_exec)

@TomasTomecek
Copy link
Member

sadly all the nested tests are failing :/ are you working for you locally?

nope and moreover, they fail from some different cause locally
(ERROR: not found: /home/sandcastle/tests/e2e/test_ironman.py::test_exec)

so you probably need to update this function: https://github.com/packit/sandcastle/blob/master/tests/conftest.py#L70

@softwarefactory-project-zuul

This comment has been minimized.

@TomasTomecek
Copy link
Member

here are my changes https://github.com/TomasTomecek/sandcastle/tree/kodink-ist-hardt

it made a test case pass for me locally:

tests/e2e/test_ironman.py::test_from_pod[test_exec-None] PASSED

if you read the code of k8s client and how they load configuration, you
may start thinking something's really iffy - that magic no longer works
in 3.9

this commit explicitly passes client.Configuration() to config.load_* so
that kubernetes doesn't need to overwrite types or w/e

there is also code here to make this work with minishift - not that it
worked for me, I ended up doing `eval $(minishft docker-env)` and make
test-image-build to get the test image into the VM - couldn't access
minishift's registry

good luck

Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
@softwarefactory-project-zuul

This comment has been minimized.

Copy link
Member

@lachmanfrantisek lachmanfrantisek left a comment

Choose a reason for hiding this comment

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

Looks good to me, but haven't tested.

raise SandcastleException(
f"We loaded the kube config but can't access any cluster. "
"We have this configutation:\n"
f"Auth: {configuration.auth_settings()}\n"
Copy link
Contributor

Choose a reason for hiding this comment

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

What kind of information does this expose? Is there anything sensitive, like API keys or passwords?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point.
Yes, it contains API key, but we raise this exception only if not configuration.api_key in which case the auth_settings() returns nothing valuable -> so we don't actually need it :-)
I'm removing it, thanks.

Copy link
Member

@TomasTomecek TomasTomecek Dec 11, 2020

Choose a reason for hiding this comment

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

I added this code because the assert config.api_key was not very clear what's wrong; this code gives at least some context what's wrong

it's true though that content of those 2 method calls is empty/nonsense-ish, so +1 removing those

@softwarefactory-project-zuul

This comment has been minimized.

- auth_settings() doesn't return anything valuable if api_key is empty
- get_host_settings() is not implemented in k8s==8.0.0
Copy link
Member

@TomasTomecek TomasTomecek left a comment

Choose a reason for hiding this comment

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

LGTM, tests are green, glad it's working again

@jpopelka jpopelka added mergeit Run Zuul's gate pipeline and merge the PR and removed mergeit Run Zuul's gate pipeline and merge the PR labels Dec 11, 2020
@softwarefactory-project-zuul
Copy link
Contributor

Build succeeded.

@jpopelka jpopelka added the mergeit Run Zuul's gate pipeline and merge the PR label Dec 11, 2020
@softwarefactory-project-zuul
Copy link
Contributor

Build succeeded (gate pipeline).

@softwarefactory-project-zuul softwarefactory-project-zuul bot merged commit 54ba93c into packit:master Dec 11, 2020
@jpopelka jpopelka deleted the npm-home branch December 11, 2020 17:50
TomasTomecek added a commit to TomasTomecek/sandcastle that referenced this pull request Jan 15, 2021
In packit#86 we started using the nss wrapper to run commands as users who
actually have passwd entries - that's awesome though for .exec() this
wasn't utilized b/c setup_env_in_openshift.sh persists only within a
shell session - exec creates new sessions

so if we want exec's to be run by "real" users, we need to source the
setup_env_in_openshift.sh script - there is a test case which verifies
this works and we have write access to $HOME

Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
TomasTomecek added a commit to TomasTomecek/sandcastle that referenced this pull request Jan 15, 2021
In packit#86 we started using the nss wrapper to run commands as users who
actually have passwd entries - that's awesome though for .exec() this
wasn't utilized b/c setup_env_in_openshift.sh persists only within a
shell session - exec creates new sessions

so if we want exec's to be run by "real" users, we need to source the
setup_env_in_openshift.sh script - there is a test case which verifies
this works and we have write access to $HOME

Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
TomasTomecek added a commit to TomasTomecek/sandcastle that referenced this pull request Jan 15, 2021
In packit#86 we started using the nss wrapper to run commands as users who
actually have passwd entries - that's awesome though for .exec() this
wasn't utilized b/c setup_env_in_openshift.sh persists only within a
shell session - exec creates new sessions

so if we want exec's to be run by "real" users, we need to source the
setup_env_in_openshift.sh script - there is a test case which verifies
this works and we have write access to $HOME

Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
TomasTomecek added a commit to TomasTomecek/sandcastle that referenced this pull request Jan 18, 2021
In packit#86 we started using the nss wrapper to run commands as users who
actually have passwd entries - that's awesome though for .exec() this
wasn't utilized b/c setup_env_in_openshift.sh persists only within a
shell session - exec creates new sessions

so if we want exec's to be run by "real" users, we need to source the
setup_env_in_openshift.sh script - there is a test case which verifies
this works and we have write access to $HOME

Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
TomasTomecek added a commit to TomasTomecek/sandcastle that referenced this pull request Jan 19, 2021
In packit#86 we started using the nss wrapper to run commands as users who
actually have passwd entries - that's awesome though for .exec() this
wasn't utilized b/c setup_env_in_openshift.sh persists only within a
shell session - exec creates new sessions

so if we want exec's to be run by "real" users, we need to source the
setup_env_in_openshift.sh script - there is a test case which verifies
this works and we have write access to $HOME

Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
TomasTomecek added a commit to TomasTomecek/sandcastle that referenced this pull request Feb 22, 2021
In packit#86 we started using the nss wrapper to run commands as users who
actually have passwd entries - that's awesome though for .exec() this
wasn't utilized b/c setup_env_in_openshift.sh persists only within a
shell session - exec creates new sessions

so if we want exec's to be run by "real" users, we need to source the
setup_env_in_openshift.sh script - there is a test case which verifies
this works and we have write access to $HOME

Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
TomasTomecek added a commit to TomasTomecek/sandcastle that referenced this pull request Feb 23, 2021
In packit#86 we started using the nss wrapper to run commands as users who
actually have passwd entries - that's awesome though for .exec() this
wasn't utilized b/c setup_env_in_openshift.sh persists only within a
shell session - exec creates new sessions

so if we want exec's to be run by "real" users, we need to source the
setup_env_in_openshift.sh script - there is a test case which verifies
this works and we have write access to $HOME

Co-authored-by: Hunor Csomortáni <csomortani.hunor@gmail.com>
Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
TomasTomecek added a commit to TomasTomecek/sandcastle that referenced this pull request Feb 23, 2021
In packit#86 we started using the nss wrapper to run commands as users who
actually have passwd entries - that's awesome though for .exec() this
wasn't utilized b/c setup_env_in_openshift.sh persists only within a
shell session - exec creates new sessions

so if we want exec's to be run by "real" users, we need to source the
setup_env_in_openshift.sh script - there is a test case which verifies
this works and we have write access to $HOME

Co-authored-by: Hunor Csomortáni <csomortani.hunor@gmail.com>
Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mergeit Run Zuul's gate pipeline and merge the PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

npm error
4 participants