I tested slurm-2.3.0-rc1 and pam_slurm on a RHEL6 system we're running and the PAM module seems to work. When I add "debug" to the options of pam_slurm in the system-auth file, I see the following in auth.log:
hype8 pam_slurm[20550]: does uid 6885 have "hype8" allocated hype8 pam_slurm[20550]: slurm_load_jobs returned 1 records hype8 pam_slurm[20550]: jobid 1011673: nodes="hype135" hype8 pam_slurm[20550]: access denied for user grondo (uid=6885) my account section in system-auth looks like: account required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_slurm.so debug When I was looking at the pam_slurm source, however, I did notice one thing that I hope the slurm developers will comment on. In commit 12ba7f70eb8909024d0684a25d6c05f4a083da22 a "no_sys_info" option was added to the pam module, but it doesn't appear to be functional (unless I'm missing something, which is quite possible). All this commit seems to do is make the "access granted|denied" log message come out twice when it is not set, and once when it is set. Is this somethimg that needs to be fixed, I don't quite understand the need for the option (more typically, pam modules have a "quiet" option) https://github.com/SchedMD/slurm/commit/12ba7f70eb8909024d0684a25d6c05f4a083da22 mark On Tue, 06 Sep 2011 13:59:11 -0700, "Mark A. Grondona" <[email protected]> wrote: > On Tue, 6 Sep 2011 13:47:18 -0700, Mark Arnold <[email protected]> > wrote: > Non-text part: multipart/alternative > > Thanks for the clarification Mark. I have commented out these pam > > modules and I get the following in the logs > > > > Sep 6 16:42:09 node048 sshd[2249]: Accepted publickey for arnoldm > > from 192.168.140.254 port 47510 ssh2 > > Sep 6 16:42:09 node048 sshd[2249]: pam_unix(sshd:session): session > > opened for user arnoldm by (uid=0) > > > > So it appears that even though I commented out the modules they are > > still being loaded. > > That is the message from the PAM session management functions, > not the account management functions (note that we are only changing > the account modules). The account stack should be run before the > session stack, but you have no other messages from sshd in the > auth logs? > > What does your /etc/pam.d/sshd file look like? Also, just to make sure, > can you remove all the lines from the account section and just have > > account required pam_slurm.so debug > > then check logs again? You could even put this directly in > /etc/pam.d/sshd if you'd like. > > mark > > > > > > -Mark > > > > On Tue, Sep 6, 2011 at 4:33 PM, Mark A. Grondona > > <[email protected]<mailto:[email protected]>> wrote: > > On Tue, 6 Sep 2011 12:19:36 -0700, Mark Arnold > > <[email protected]<mailto:[email protected]>> wrote: > > Non-text part: multipart/alternative > > > Hi Jerry, > > > > > > Thanks for the quick response. I just tried commenting that line, but > > > it had no affect on blocking the users that had not allocated the > > > node. As a side note, I have 2 other clusters that have that included > > > and it works correctly... > > > > I also think Jerry is on the right track with his suggestion. That > > commenting out pam_permit.so didn't change the outcome says to me > > that one of the modules before pam_permit.so is allowing the users > > to log in. Note that pam_succeed_if.so and pam_access are both > > "sufficient" to allow access, so they short-circuit the rest of > > the tests. To test this, comment out the rest of the PAM modules > > from the account section, as an experiment. > > > > I think most of these modules, including pam_slurm, allow > > a "debug" option so you can get extra debuggin in the auth.log. > > > > So you could also try > > > > account required pam_unix.so > > account sufficient pam_succeed_if.so uid < 500 > > account sufficient pam_access.so debug > > account required pam_slurm.so debug > > > > Then check the logs to see which module allowed access to the node. > > > > mark > > > > > > > > > > > > -Mark > > > > > > On Tue, Sep 6, 2011 at 2:58 PM, Jerry Smith > > > <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > > > wrote: > > > I think this may be due to the line: > > > > > > > > > account required pam_permit.so > > > > > > We have this commented out on our production machines. > > > > > > From the manpage > > > > > > This module is very dangerous. It should be used with extreme > > > caution. > > > RETURN VALUES > > > PAM_SUCCESS > > > This module always returns this value. > > > > > > EXAMPLES > > > Add this line to your other login entries to disable account > > > management, but continue to permit users to log in. > > > > > > > > > account required pam_permit.so > > > > > > > > > > > > > > > Mark Arnold wrote: > > > Recently I upgraded our cluster from RHEL5 to RHEL6. After the upgrade > > > the slurm PAM module no longer seems to work properly (I had built new > > > rpms from the 2.2.7 SRPM on the compute nodes and installed those rpms > > > everywhere). The problem is that it still allows users to log in whether > > > or not they have an allocation for that node. I believe it is partially > > > working because it does block a user from running sudo on a node they do > > > not have allocated while if they do have it allocated they can run sudo. > > > I've been doing a lot of searching but I haven't run across anyone else > > > that has a similar issue. Everything I have found basically says install > > > the rpm, modify the /etc/pam.d/system-auth file and that is it. > > > > > > I'm not sure what else to do, so any help would be greatly appreciated. > > > > > > Thanks, > > > > > > Mark > > > > > > Here is my system-auth file > > > > > > #%PAM-1.0 > > > # This file is auto-generated. > > > # User changes will be destroyed the next time authconfig is run. > > > auth required pam_env.so > > > auth sufficient pam_unix.so nullok try_first_pass > > > auth requisite pam_succeed_if.so uid >= 500 quiet > > > auth required pam_deny.so > > > > > > account required pam_unix.so > > > account sufficient pam_succeed_if.so uid < 500 quiet > > > account sufficient pam_access.so > > > account required pam_permit.so > > > account required pam_slurm.so > > > > > > password requisite pam_cracklib.so try_first_pass retry=3 > > > password sufficient pam_unix.so md5 shadow nis nullok > > > try_first_pass use_authtok > > > password required pam_deny.so > > > > > > session optional pam_keyinit.so revoke > > > session required pam_limits.so > > > session [success=1 default=ignore] pam_succeed_if.so service in crond > > > quiet use_uid > > > session required pam_unix.so > > > > > > > > > [root@head ~]# scontrol show config > > > Configuration data as of 2011-09-06T13:32:36 > > > AccountingStorageBackupHost = (null) > > > AccountingStorageEnforce = none > > > AccountingStorageHost = localhost > > > AccountingStorageLoc = /var/log/slurm_jobacct.log > > > AccountingStoragePort = 0 > > > AccountingStorageType = accounting_storage/none > > > AccountingStorageUser = root > > > AuthType = auth/munge > > > BackupAddr = (null) > > > BackupController = (null) > > > BatchStartTimeout = 10 sec > > > BOOT_TIME = 2011-09-04T16:48:50 > > > CacheGroups &b=== > > > > > Non-text part: text/html > > > Non-text part: text/html
