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.
Which circles back to the big issue with most container environments: security.
You should not allow full access to root inside your container (or other environments). Use sudoers and be highly restrictive with what commands are allowed. If that is not possible, you need to trust the people you give the permission to that they will not abuse it.
Brian Andrus On 5/18/2022 12:22 AM, GHui wrote:
Hi, Brian Andrus I think the main poblem is that container can cheat Slurm. On 5/17/22 06:58:20, 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 > >> On 5/17/22 7:49 AM, GHui wrote: >> 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 container-id /bin/bash" to login with host user rsync. And the user is root on container. >> Now I submit job with root in container. And job is running on host. And the job's owner is root. >> So I submit a job with user rsync, but it runs as root privilege. >> >> 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 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. >>> --GHui
