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
