-
Notifications
You must be signed in to change notification settings - Fork 16
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
Arbitrary user ID is comming $HOME #86
Conversation
This comment has been minimized.
This comment has been minimized.
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.
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} |
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.
this should ideally be owned by sandcastle user
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.
there's no such user at the time of building the image
5d0f1a1
to
e773a2a
Compare
Build failed.
|
nope and moreover, they fail from some different cause locally |
so you probably need to update this function: https://github.com/packit/sandcastle/blob/master/tests/conftest.py#L70 |
This comment has been minimized.
This comment has been minimized.
here are my changes https://github.com/TomasTomecek/sandcastle/tree/kodink-ist-hardt it made a test case pass for me locally:
|
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>
This comment has been minimized.
This comment has been minimized.
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.
Looks good to me, but haven't tested.
sandcastle/api.py
Outdated
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" |
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.
What kind of information does this expose? Is there anything sensitive, like API keys or passwords?
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.
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.
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.
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
This comment has been minimized.
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
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.
LGTM, tests are green, glad it's working again
Build succeeded.
|
Build succeeded (gate pipeline).
|
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>
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>
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>
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>
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>
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>
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>
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>
(hopefully) Fixes #85
Trying in 2 terminals