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
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.