(In reply to hpc-admin from comment #0)
> Currently we use salloc --uid/gid to automatically submit user's job to a
> (root only) partition where we do not want them to submit jobs themselves.
> According to bug CVE-2019-19728, srun --uid/gid functionality might be
> removed in the future. My question is how does this affect salloc --uid/gid
> functionality? And if it is also planned to remove, then what alternatives
> could you suggest? Additionally could you update the manual of salloc and
> srun with the status of uid/gid option (for example whether it is
> recommended and might be removed in the future?)

I do expect to remove it in a later release, but it is still in place now and in the 20.02 release.

I would recommend reworking these workflows to use 'su'.

The --uid functionality has a number of shortcomings - most importantly that it does not reset into the users' environment so you could potentially leak sensitive environment variables into their jobs. If the root environment contains access tokens or other sensitive data a user could recover that, although I will not describe the process for that here.

I will look at updating the man pages.

Using just su does not solve the problem for a separate partition for automated job submissions. Currently we have a cluster with a public and and a root only partition. The root only partition takes automatically submitted jobs only, and obviously we do not want users to submit themselves jobs there. If I rework the automatic submission workflow from "salloc --uid user --gid user srun ...." to "sudo -u user salloc srun..." what will prevent users to submit jobs into this partition?

Our solution to prevent leaking sensitive environmental variables to user's job that we use a clean dummy user to submit automated jobs using sudo.