[slurm-users] slurm x11 forward and NFS

[Jerzy Borkowski]

Hi,

slurm 17.11.7 does not seem to properly set X11 authority
when ~/.Xauthority is mounted via NFS.
The typical command displays :

medusa-01:/home/xxx>srun -p pshort --x11 --pty /bin/bash
xxx at node-10 ~ $ xdpyinfo
X11 connection rejected because of wrong authentication.
xdpyinfo:  unable to open display "localhost:21.0".

If I add manually on node-10 the missing xauth record

  xauth add node-10/unix:21 MIT-MAGIC-COOKIE-1 1234567890abcdef......

then X11 works. Looking into the code, slurmd does :


5016  setresgid(-1, 1111, -1)           = 0
5016  setgroups(1, [1111])              = 0
5016  setresuid(-1, 2222, -1)           = 0
5016  socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 11
5016  setsockopt(11, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
5016  bind(11, {sa_family=AF_INET, sin_port=htons(6088),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
5016  listen(11, 1024)                  = 0
5016  access("/usr/bin/xauth", R_OK|X_OK) = 0
5016  pipe([17, 18])                    = 0
5016  clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x14dbccbafa50) = 5017
5016  close(18)                         = 0

then calls fork+execv(/usr/bin/xauth).
xauth does the following :

5017 access("/home/xxx/.Xauthority", F_OK) = 0
5017 access("/home/xxx/.Xauthority", W_OK) = -1 EACCES (Permission denied)
5017 write(2, "xauth:  /home/xxx/.Xauthority not writable, changes will
be ignored\n"..., 68 <unfinished ...>
5017 <... write resumed> )             = 71
5017 umask(077 <unfinished ...>
5017 <... umask resumed> )             = 022
5017 brk(NULL)                         = 0x232d000
5017 brk(0x234e000)                    = 0x234e000
5017 open("/home/xxx/.Xauthority", O_RDONLY) = 3
5017 fstat(3, {st_mode=S_IFREG|0600, st_size=737, ...}) = 0

Unfortunately access(W_OK) fails because it uses RealUID (which is root,
mapped to nobody on NFS)
in its computations (as per man-page)
Subsequent open() succeeds because it uses EUID (non-root).

I'm not sure whether it is a bug in slurm or in xauth.

best regards,

jb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20180712/9b598d4a/attachment.html>