Ghui,
It seems that things are doing what they should.
You are allowing an account to become root inside the pod and the pod is
considered a trusted environment by slurm (you are running munge inside it).
So as far as slurm is concerned, 'root' from a trusted environment is
submitting a job.
> I had config the right slurm and munge inside the container.
this is the reason.
Who has access to munge.key can effectively became root at slurm cluster.
you should not disclose munge.key to containers.
cheers
josef
On 18. 05. 22 9:13, GHui wrote:
...I had config the right slurm and
Hi,
On 18.05.22 08:25, Stephan Roth wrote:
Personal note: I'm not sure what I'd choose as a successor to
Singularity 3.8, yet. Thoughts are welcome.
I can recommend nvidia enroot/pyxis.
enroot does unprivileged sandboxes/containers, pyxis is the slurm SPANK
glue.
On 17.05.22 17:17, Timo Rothenpieler wrote:
On 17.05.2022 15:58, Brian Andrus wrote:
You are starting to understand a major issue with most containers.
I suggest you check out Singularity, which was built from the ground
up to address most issues. And it can run other container types (eg:
On 17.05.2022 15:58, Brian Andrus wrote:
You are starting to understand a major issue with most containers.
I suggest you check out Singularity, which was built from the ground up
to address most issues. And it can run other container types (eg: docker).
Brian Andrus
Side-Note to this,
Hi GHui,
fyi: I am not a podman-expert so my questions might be stupid. :-)
From what you told us so far you are running the podman-command as
non-root but you are root inside the container, right?
What is the output of "podman info | grep root" in your case?
How are you submitting a job
You are starting to understand a major issue with most containers.
I suggest you check out Singularity, which was built from the ground up
to address most issues. And it can run other container types (eg: docker).
Brian Andrus
On 5/16/2022 10:49 PM, GHui wrote:
I use podman 4.0.2. And slurm
I use podman 4.0.2. And slurm 21.08.8-2.
I run container on my host with username rsync. And it only has itself
privilege.
I create the same username, UID and GID in container with the host.
I run "podman exec -it /bin/bash" to login with host user rsync.
And the user is root on container.
Now
In fact, that is something, that I would expect. In my opinion, that is a
misconfiguration of the container.
If on bare metal I do a sudo -u and then submit a job, I would expect
that to be submitted as newuser, and not as the old one.
Best
Marcus
Am 16.05.2022 um 10:01 schrieb Hermann
Hi GHui,
I have a few questions regarding your mail:
* What kind of container are you using?
* How exactly do you switch to a different user inside the container?
Regards,
Hermann
On 5/16/22 7:53 AM, GHui wrote:
I fount a serious problem. If I run a container on a common user, eg. tom. In
On 5/16/22 07:53, GHui wrote:
I fount a serious problem. If I run a container on a common user, eg. tom. In
container I switch user to jack, now, if I submit a job to slurm cluster, the
job owner is jack.
So I use the tom account submit a jack's job.
Any help will be appreciated.
You must
11 matches
Mail list logo
