4

Background: I am using a Debian 7 system which I have integrated with an LDAP+Kerberos system using libnss-ldap, libpam-krb5 and nscd. I have modified sudoers to permit an LDAP group the right to sudo and gain super-user privileges. Hence, I can log in as an LDAP group to manage the machine. This is all working fine, and ssh login works well with an LDAP user.

I was just experimenting with a .k5login file in the home directory of my user account, Cosmic Ossifrage. In the file, I listed:

cosmic_ossifrage@REALM.COM

which is a valid Kerberos identity. SSH logins as this user continued to work correctly with the .k5login file in place.

However, with this .k5login file in my home directory, I was no longer able to use sudo -i to gain super-user privileges. This does not seem to make any sense, since the .k5login is in my home directory, not root's, so to my mind, neither the root user, nor the sudo command, should be restricted any further than what is present in the sudoers file.

However, with the .k5login file as above in place, neither sudo -i nor sudo su were working whereas they were before. Once the .k5login file was removed, this functionality was restored and I was able to sudo again.

In the log file /var/log/auth.log, among the many error messages reported at this time was one from sudo, stating:

[pam:sudo] krb5_kuserok failed for user cosmic_ossifrage

Did I miss something fundamental in the definition of what a .k5login is supposed to do? Is this expected behaviour, and if so, why?

  • 1
    Are these requirements met on the .k5login: "The .k5login file must contain one principal per line, be owned by user, and not be writable by group or other (but must be readable by anyone)." – Mark Wagner Jul 1 '14 at 0:02
  • D'oh! I think you may have hit the nail on the head. must be readable by anyone might be the issue -- I will have to check and get back to you. – Cosmic Ossifrage Jul 1 '14 at 13:35
  • If this was resolved, it would be nice to know the solution. I'm looking for something similar to this. – quux00 Sep 17 '14 at 20:28
  • @quux00 The issue was that the network location where the home directories were stored, and hence where the .k5login file resided, was restricting access to only the user concerned (and root squashing was of course enabled). Adding world readable permissions for the .k5login file resolved the difficulties. – Cosmic Ossifrage Sep 20 '14 at 15:01
0

As per Mark's comment, the .k5login file must satisfy the following requirements:

The .k5login file must contain one principal per line, be owned by user, and not be writable by group or other (but must be readable by anyone).

as per the comments found in the Kerberos source code.

In this instance, the .k5login file was not readable by anybody but the Cosmic Ossifrage user. The NFS mount on which the user's home directory was stored also enforced root squashing, prohibiting access by even the root user. By making the file world-readable, sudo to root functionality was returned.

(Marking community wiki, as the answer originally came from a comment.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.