Mark, We were, in fact, able to get the correct behaviour with
----- #%PAM-1.0 auth include system-auth account required pam_nologin.so account include system-auth password include system-auth session optional pam_keyinit.so force revoke session include system-auth session required pam_loginuid.so ------- Thanks! Andy On 08/24/2012 05:19 PM, Mark A. Grondona wrote: > "Mark A. Grondona" <[email protected]> writes: > >> What version of SLURM and glibc? >> >> I can't get this to reproduce with slurm-2.3 and RHEL6 version >> of glibc. >> >> I think getlogin() is looking at the utmp entry for the tty connected >> to fd 0 (stdin) of the process calling getlogin(3). I am surprised it >> returns anything for normal jobs (no tty), and I'm surprised it works >> for me since I doubt slurm adds a utmp entry. >> >> However, checking utmp for a running job might be interesting, and >> a workaround might involve setting a utmp entry for slurm jobs >> via a plugin. > I did 5 more minutes of digging. > > It appears that on our systems we have > > session required pam_loginuid.so > > in the PAM stack for slurm. > > This PAM module sets the loginuid for all processes spawned > in slurm jobs, and a quick test with strace seems to show > that /proc/self/loginuid is a fallback (or maybe preferred) > source for getlogin(3). > > So if you're lucky, perhaps adding the above line to the > slurm pam stack will "fix" this problem ;-) > > mark > > >> mark >> >> Andy Riebs <[email protected]> writes: >>> The following trivial program returns "root" when run under SLURM, even >>> though neither SlurmUser nor the current user is root. (Predictably, >>> this is in user code that we can't change.) Is there a configuration >>> setting that we could be using to avoid letting getlogin() think we are >>> root? >>> >>> The program: >>> >>> ----------- >>> #include <stdio.h> >>> #include <unistd.h> >>> >>> int >>> main() >>> { >>> printf("getlogin() returns \"%s\"\n", getlogin()); >>> return 0; >>> } >>> ---------- >>> >>> Andy >>> >>> -- >>> Andy Riebs >>> Hewlett-Packard Company >>> High Performance Computing >>> +1-786-263-9743 >>> My opinions are not necessarily those of HP -- Andy Riebs Hewlett-Packard Company High Performance Computing +1-786-263-9743 My opinions are not necessarily those of HP
