On Tue, 6 Sep 2011 14:30:44 -0700, Mark Arnold <[email protected]> wrote: Non-text part: multipart/alternative > Thanks for the update. I was looking in /var/log/secure as I don't > have an auth.log on that system, but even after adding the debug > option I got no additional output. > > What did the /etc/pam.d/sshd file look like on that system?
This system isn't running sshd, but is instead using a specialized rsh server (based on munge authentication). The mrlogin pam stack looks like: auth requisite pam_nologin.so auth required pam_localuser.so auth required pam_shells.so auth required pam_securetty.so account include system-auth session include system-auth That is why we place pam_slurm in system-auth's "account" stack. (Note that "login" "sudo" "passwd" "chsh" etc. also use system-auth) mark > Thanks again, > > Mark > > On Tue, Sep 6, 2011 at 5:24 PM, Mark A. Grondona > <[email protected]<mailto:[email protected]>> wrote: > > 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]<mailto:[email protected]>> wrote: > > On Tue, 6 Sep 2011 13:47:18 -0700, Mark Arnold > > <[email protected]<mailto:[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]><mailto:[email protected]<mailto:[email protected]>>> > > > wrote: > > > On Tue, 6 Sep 2011 12:19:36 -0700, Mark Arnold > > > <[email protected]<mailto:[email protected]><mailto:[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]>><mailto:[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 > Non-text part: text/html
