<div dir="ltr"><div>Thanks a lot for your answers again!</div><div><br></div><div>@Marcus Thanks a lot for the clarification. <br></div><div><br></div><div>About --uid, you are correct, I was mistyping it as -uid. But, the behaviour is slightly inconsistent:</div><div>* If correctly typed (--uid) sbatch properly complains about needing to be root</div><div>* If not present at all, or ignored (by adding a non-commented line before, like you said), everything goes fine</div><div>* If incorrectly typed (-uid UID), it silently fails UNLESS /home/UID/d exists, then it is run as the requested user, i.e. if I add <br></div><div><br></div><div>#SBATCH -uid test2</div><div><br></div><div>the log complains about /home/test2/d not existing. After creating that file as test2 (that is, the file /home/test2/d is -rw-r--r-- test2:test2), it executes the task as test (i.e. the output is, by default, in /home/test and owned by test). I guess this is a bug?</div><div><br></div><div>@Jeffrey Sorry, <span class="gmail-im">slurmdUser=sudo was a typo. Thanks a lot for the clarifications regarding the POSIX capabilities.</span></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 9 Jul 2019 at 14:49, Jeffrey Frey <<a href="mailto:frey@udel.edu">frey@udel.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> So, if I understand this correctly, for some reason, `srun` does not need root privileges on the computation node side, but `sbatch` does when scheduling. I was afraid doing so would mean users could do things such as apt install and such, but it does not seem the case.<br>
<br>
The critical part here is slurmstepd running as one user (root, or slurm in your case) attempting to seteuid/setegid/setreuid/setregid the process.  If not running as root, you'll see in the slurmstepd source code that the seteuid/setegid/setreuid/setregid calls are skipped -- thus, all job tasks run as SlurmdUser.  On a multiuser system, SlurmdUser=root is necessary and safe.<br>
<br>
<br>
<br>
> I am not going to be managing the actual cluster, only exploring possibilities. At this point I am mostly convinced slurmdUser=sudo is safe, so that is one less potential problem.<br>
<br>
SlurmdUser must be set to a user name present on the machine.  Setting it to "sudo" merely has it run as a user named "sudo."<br>
<br>
<br>
> @Patrick: I do not know how to do that. I only know that I can make slurm sudoer and NOPASSWD, but slurm would still call to `chown` (not `sudo chown`). An alternative would be replacing `chown` with a small script that calls `sudo chown`, but that is likely to break a lot of stuff. I assume slurmd will also need other root-only commands to work.<br>
<br>
The chown in question is a chown() system call in the slurmd/slurmstepd source code that's compiled into slurmd/slurmstepd.  Replacing /usr/bin/chown with a custom command that calls sudo would not help at all (and would probably create a security issue).<br>
<br>
<br>
> @Michael Indeed, the documentation/tutorials often mention that SlurmdUser should be root, but it is not clearly explained why anywhere (e.g. <a href="https://slurm.schedmd.com/quickstart_admin.html" rel="noreferrer" target="_blank">https://slurm.schedmd.com/quickstart_admin.html</a> section Daemons). It seems that `srun whoami` returns the current user (and not root), so even when slurmdUser is root, users do not have privileges, so in principle there is no problem at all.<br>
<br>
Again, the critical part here is slurmstepd's having the ability to change the running uid/gid of the processes it starts.  With SlurmdUser=root, it can do this.  With any other user name, it cannot, and every job step runs as SlurmdUser.<br>
<br>
<br>
<br>
> @Jeffrey It is expected to be multi-user. As for your third option, I think you refer to something similar to what I wrote for Patrick. <br>
<br>
I was talking about POSIX capabilities, and the possibility that all the capabilities exist to grant to slurmstepd the ability to chown() like root can, etc.  That still doesn't help with the seteuid/setegid/setreuid/setregid calls because slurmstepd doesn't even make those calls when it's not running as root.<br>
<br>
<br>
<br>
<br>
::::::::::::::::::::::::::::::::::::::::::::::::::::::<br>
Jeffrey T. Frey, Ph.D.<br>
Systems Programmer V / HPC Management<br>
Network & Systems Services / College of Engineering<br>
University of Delaware, Newark DE  19716<br>
Office: (302) 831-6034  Mobile: (302) 419-4976<br>
::::::::::::::::::::::::::::::::::::::::::::::::::::::<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>