diehn.net/blog

I’m building a cluster of 25 machines at work. Trying to get the Infiniband stuff to work on them – a dev found an annomoly in his benchmarking numbers and asked me to verify his work and look for trouble and so – I did. While I was doing it, I found some other users in the company had discovered the new cluster’s component systems as “non-busy servers to play with” and had – uhm – started using them for – uhm – stuff that makes them busy as heck. Never mind. BOFH foder.

These boxen all run openSUSE 10.3. We have them NISed up, but otherwise, they’re pretty much stock. Used to be, we’d limit user access to people in a specific netgroup via the ‘hack the /etc/passwd’ file trick something like this:

userx:X:uid:gid:asdfasdf.a.sdf.as.df.asdfasdf 
usery:X:uid:gid:asdfasdf.a.sdf.as.df.asdfasdf 
userx:X:uid:gid:asdfasdf.a.sdf.as.df.asdfasdf 
+@netgroup_to_let_in::::::
+::::::/bin/false

The idea being that members of NIS netgroup_to_let_in would match the first + line and get in because their shell would be used instead of the shell for the catch-all at the bottom.

That appears to work for some systems here and not for others. I haven’t yet figured out which systems like that and which don’t and I got sick of fiddling with it. So I needed a new, real, reliable, actual method. And this real, actual method thing I found works intuitively. (I say found. As if it were a new thing. No. I just read a manual…)

Go define a new netgroup, call it newclustertesters, say.

Then, put this in the /etc/security/access.conf:

#
# 2008-01-22 mdiehn: restricting access while testing the new cluster systems
#    so my benchmarks aren't tainted by stray user processes.  Like Xvnc. :-)
#
+ : sgeadmin : ALL
+ : root : ALL
+ : @sysadm : ALL
+ : @csnh : ALL
+ : @newclustertesters : ALL
- : ALL : ALL

Then edit either /etc/pam.d/common-account (or the specific files for sshd, rlogin, login, etc.) and add this line right after all the other “account” lines. I’ll show before and after for the /etc/pam.d/common-account file:

Before:

account required        pam_unix2.so

After

account required        pam_unix2.so
account required        pam_access.so

OK, and here’s a B&A on a ficticious /etc/pam.d/sshd in a system on which the admin decided not to put the pam_access.so in the common-account file:

Before

auth     requisite      pam_nologin.so
auth     include        common-auth
account  include        common-account
password include        common-password
session  required       pam_loginuid.so
session  include        common-session

After

auth     requisite      pam_nologin.so
auth     include        common-auth
account  include        common-account
account  required       pam_access.so
password include        common-password
session  required       pam_loginuid.so
session  include        common-session

So, the /etc/security/access.conf file has pretty good documentation in it – go read that. And if you want it direct from the horse:

http://www.kernel.org/pub/linux/libs/pam/modules.html – Primary site for PAM distribution and documentation