[slurm-users] Prolog and job_submit
Chris Samuel
chris at csamuel.org
Mon Oct 31 05:32:40 UTC 2022
On 30/10/22 12:27 pm, Davide DelVento wrote:
> But if I understand correctly your Prolog vs TaskProlog distinction,
> the latter would have the environmental variable and run as user,
> whereas the former runs as root and doesn't get the environment,
That's correct. My personal view is that injecting arbitrary input from
a user (such as these environment variables) would make life hazardous
from a security point of view for a root privileged process such as a
prolog.
> not even from the job_submit script.
That is correct, all the job_submit will do is inject the environment
variable into the jobs environment, just as if a user had done so.
> The problem with a TaskProlog
> approach is that what I want to do (making a non-accessible file
> available) would work best as root. As a workaround is that I could
> make that just obscure but still user-possible. Not ideal, but better
> than nothing as it is now.
>
> Alternatively, I could use another way to let the job_submit lua
> script communicate with the Prolog, not sure exactly what (temp
> directory on the shared filesystem, writeable only by root??)
My only other thought is that you might be able to use node features &
job constraints to communicate this without the user realising.
For instance you could declare the nodes where the software is installed
to have "Feature=mysoftware" and then your job submit could spot users
requesting the license and add the constraint "mysoftware" to their job.
The (root privileged) Prolog can see that via the SLURM_JOB_CONSTRAINTS
environment variable and so could react to it.
Then when 23.02 comes out you could use the new SLURM_JOB_LICENSES
environment variable in addition and retire the old way once jobs using
the old method have completed.
> Thanks for pointing to that commit. I bit too down the road but good to know.
No worries, best of luck!
All the best,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Berkeley, CA, USA
More information about the slurm-users
mailing list