I see. Thanks a lot for the in depth explanation. On Tue, 9 Jul 2019 at 16:27, Jeffrey Frey <f...@udel.edu> wrote:
> "-uid" is a perfectly valid sbatch flag: > > > -u, --usage > Display brief help message and exit. > > -i, --input=<filename pattern> > Instruct Slurm to connect the batch script's standard input > directly to the file name specified in the > "filename pattern". > > By default, "/dev/null" is open on the batch script's > standard input and both standard output and stan‐ > dard error are directed to a file of the name > "slurm-%j.out", where the "%j" is replaced with the job > allocation number, as described below in the filename > pattern section. > > > What you've specified with "-uid" is: > > > --usage --input=d > > > > Since the "--usage" appears in the script header and not from the cli > args, it's ignored. That leaves just > > > --input=d > > > > So your job script's STDIN is connected to a file named "d" in the working > directory at time of submission: > > > JobId=596862 JobName=x.qs > : > StdErr=/home/1001/slurm-596862.out > StdIn=/home/1001/d > StdOut=/home/1001/slurm-596862.out > Power= > > > > On Jul 9, 2019, at 11:13 AM, Daniel Torregrosa < > daniel.torregr...@insight-centre.org> wrote: > > Slight correction, it does not look for a file named "d" in the home > folder of the user in the (mistyped) -uid parameter, it looks for a file > named "d" in the home folder of the user running sbatch. If this is not an > expected behaviour, I will make a complete bug report. > > > > On Tue, 9 Jul 2019 at 15:53, Daniel Torregrosa < > daniel.torregr...@insight-centre.org> wrote: > Thanks a lot for your answers again! > > @Marcus Thanks a lot for the clarification. > > About --uid, you are correct, I was mistyping it as -uid. But, the > behaviour is slightly inconsistent: > * If correctly typed (--uid) sbatch properly complains about needing to be > root > * If not present at all, or ignored (by adding a non-commented line > before, like you said), everything goes fine > * 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 > > #SBATCH -uid test2 > > 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? > > @Jeffrey Sorry, slurmdUser=sudo was a typo. Thanks a lot for the > clarifications regarding the POSIX capabilities. > > > On Tue, 9 Jul 2019 at 14:49, Jeffrey Frey <f...@udel.edu> wrote: > > 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. > > 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. > > > > > 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. > > 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." > > > > @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. > > 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). > > > > @Michael Indeed, the documentation/tutorials often mention that > SlurmdUser should be root, but it is not clearly explained why anywhere > (e.g. https://slurm.schedmd.com/quickstart_admin.html 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. > > 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. > > > > > @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. > > 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. > > > > > :::::::::::::::::::::::::::::::::::::::::::::::::::::: > Jeffrey T. Frey, Ph.D. > Systems Programmer V / HPC Management > Network & Systems Services / College of Engineering > University of Delaware, Newark DE 19716 > Office: (302) 831-6034 Mobile: (302) 419-4976 > :::::::::::::::::::::::::::::::::::::::::::::::::::::: > > > > > > > > :::::::::::::::::::::::::::::::::::::::::::::::::::::: > Jeffrey T. Frey, Ph.D. > Systems Programmer V / HPC Management > Network & Systems Services / College of Engineering > University of Delaware, Newark DE 19716 > Office: (302) 831-6034 Mobile: (302) 419-4976 > :::::::::::::::::::::::::::::::::::::::::::::::::::::: > > > > >
