Hide Forgot
ksu as packaged in krb5-workstation-1.13.2-12.el7_2 seems to ignore the option 'k5login_directory' set in /etc/krb5.conf and always looks in the user's homedir for the .k5login file. Steps to Reproduce: 1. Edit /root/.k5login - add a valid principal. 2. ksu root -n <principal> 3. mv /root/.k5login /etc/k5login/root 4. Edit krb5.conf - add 'k5login_directory = /etc/k5login 4. ksu root -n <principal> # Account root: authorization of <principal> failed An strace of the ksu process shows that it is always trying to open /root/.k5login, regardless of the state of k5login_directory option. Other commands (e.g. ssh) honour this config option as expected.
Can you please provide strace logs which include how strace was invoked? ksu is a setuid program and I would like to verify the interaction between it and strace.
A little wary of posting a whole strace of a ksu process, in case any csecrets end up in it, but I'm running it as follows (using principal mattr@REALM): sudo strace -fF -o /tmp/ksu.out sudo -u mattr ksu root -n mattr Looking at all stats, reads etc in strace the only apparent ones of relevance are: 3872 stat("/root/.k5login", 0x7ffcf3955b40) = -1 ENOENT (No such file or directory) 3872 stat("/root/.k5users", 0x7ffcf3955b40) = -1 ENOENT (No such file or directory) This is the same regardless of the state of k5login_directory option. I've had a quick look at the source in the src rpm, and it does look like this is hard-coded for ksu. lib/krb5/os/localauth_k5login.c provides a 'get_k5login_filename' method which does the 'try k5login_directory/look in homedir' logic. However this doesn't seem to be called anywhere in clients/ksu/ with ksu.h having: #define KRB5_LOGIN_NAME ".k5login" #define KRB5_USERS_NAME ".k5users" Which is then used through the rest of ksu's code. I've had a quick look at the latest upstream code from MIT and ksu.h looks pretty identical, so I suspect this is really an upstream bug... don't know if that's something I need to open separately with the krb5 project, or if this bug report can be 'redirected' to them?
(In reply to Matthew Richardson from comment #4) > A little wary of posting a whole strace of a ksu process, in case any > csecrets end up in it, but I'm running it as follows (using principal > mattr@REALM): Sorry, assumed you had a realm set up for testing not something in production. The information you've provided should be (more than) sufficient; thanks!
Created upstream ticket to track this.