Hi,
Ah okay, so your requirements include completely insulating (some)
jobs from outside access, including root?
Correct.
I've seen this kind of requirements on e.g. working non-defaced
medical data - generally a tough problem imo because this level of
data security seems more or less incompa
Hi,
Thanks for the suggestion.
However as I understand it this requires additionally trusting the
node where those scripts are running on,
which is, I guess, the one running SlurmCtlD.
The reason we are using Prolog scripts is that they are running on the
very node the job will be running o
job_submit.lua allows you to view (and edit!) all job parameters that
are known at submit time, including the option to refuse a configuration
by returning `slurm.ERROR`instead of `slurm.SUCCESS`. The common way to
filter for interactive jobs in job_submit.lua is checking whether
job_desc.script i
Hello Alex,
I'd suggest taking a look at Slurm's Lua plugins for these kind of problems:
https://slurm.schedmd.com/cli_filter_plugins.html
https://slurm.schedmd.com/job_submit_plugins.html
As far as I understand it, cli_filter.lua is geared towards controlling
the use of specific commandline o
Hi,
we do some additional checking on a user and the batch script in a
Prolog script.
However the `--no-allocate`/`-Z` bypasses allocation and hence execution
of the Prolog/Epilog.
Is there a way to configure SlurmD to deny access to jobs without
allocations or more generally all interactive
