I and two or three student assistants administer my RHEL/CentOS 6.2 machine. Since I don't need to limit their powers, we use "su" rather than "sudo."
When I "su -" to root from my account, the operation is essentially instantaneous. From the accounts of both of my assistants, the "su -" command takes at least 45 seconds. (!!) I've also tested a couple of random user accounts, and it's 45+ seconds for those, too. It seems that only for my own account is it quick. All the accounts are essentially equivalent. They live in an LDAP database, hosted on the same RHEL 6 server. They have the same login shell. I can't think of any reason why they should be different.
Correction: They are almost the same, but the home directories are on different filesystems: The "su" is quick from several accounts that I tested where the home directory is in the /home partition. The "su" is slow from my student assistants, where the home directory is in the /students partition. These are both ext4 filesystems that are on the local RAID drive, so they are identical in terms of performance, locality to the machine, etc. The only difference is that there is (now) a quota set for the /students partition. However, this slowness pre-dates adding the ",usrquota,grpquota" mount options, so we can't blame the slowness on quotas. Still, it seems likely that the slowness has to do the filesystem partition. Note that su *to* an account in /students is just as fast as an su *to* an account in /home.
More data: The root username and password are in /etc/passwd and /etc/shadow, respectively. I have verified both the "setup" and "coreutils" RPM packages, and neither has been modified.
I thought it might perhaps be a caching sort of issue, but it continues to be slow even if I try several times in a row.
I tried doing an strace on the "su -" command, but for some reason the root password fails when I use strace. (No, I'm not repeated mis-typing the root password whenever I use strace; somehow, strace interferes with the functioning of the "su" command.) I can even see the root password in the strace output, and I know that it is being typed correctly. I noticed via the strace log that /etc/passwd is opened five times but that /etc/shadow is never opened, so I thought that was odd. But the core problem is that "su" is slow, not that I can't use "strace" on "su," so we don't really have to debug "strace."
I'm stumped. This is merely an annoyance, not a lack of function, but it's very annoying, and I'd appreciate any suggestions you have.
Here's some more information: One of my colleagues looked in /var/log/audit.log and found a bunch of avc denials until, finally, it gives up and lets the "su" proceed. So, the problem is an selinux problem (oh, joy). He also found the following:
http://docs.redhat.com/docs/en-US/Re...ide/#id2839255 which suggests that the selinux context will be wrong for home directories that aren't in /home, which perfectly describes my situation. So, now I have to try to understand what's going on with having custom home directories. Unfortunately, I don't really understand the directions in the RHEL deployment guide, and I don't have "semanage" installed on my machine and I can't figure out what yum package supplies it.
Ok, that last bit seems to have done it. Guessing the semanage is in /usr/sbin/ and doing
# yum provides /usr/sbin/semanage
told me that it's provided by policycoreutils-python, which was easy to install. I then guessed that the RHEL documentation intended that /home/locale is the custom home dir, so I did
# semanage fcontext -a -e /home /students
# restorecon -R -v /students
That second command takes a while!
But, now, "su" is equally quick for my student assistants and for me!
Thanks, Scott
