On Tue, 6 Sep 2011 12:19:36 -0700, Mark Arnold <[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]>> 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
