Bug 965989 - kadmin.local fails when adding a principal in ipa-server-install
kadmin.local fails when adding a principal in ipa-server-install
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: freeipa (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rob Crittenden
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-22 05:00 EDT by Tomas Babej
Modified: 2013-06-14 00:48 EDT (History)
11 users (show)

See Also:
Fixed In Version: freeipa-3.2.1-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-14 00:48:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Babej 2013-05-22 05:00:07 EDT
Description of problem:

When running ipa-server-install on F19:

[snip]
one configuring certificate server (pki-tomcatd).
Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds
  [1/10]: adding sasl mappings to the directory
  [2/10]: adding kerberos container to the directory
  [3/10]: configuring KDC
  [4/10]: initialize kerberos container
  [5/10]: adding default ACIs
  [6/10]: creating a keytab for the directory
Unexpected error - see /var/log/ipaserver-install.log for details:
CalledProcessError: Command 'kadmin.local -q addprinc -randkey ldap/vm-001.ipa.com@IPA.COM -x ipa-setup-override-restrictions' returned non-zero exit status 1

The relevant part of ipaserver-install.log tells us that credential cache directory does not exist.

2013-05-22T08:32:25Z DEBUG   [6/10]: creating a keytab for the directory
2013-05-22T08:32:25Z DEBUG Starting external process
2013-05-22T08:32:25Z DEBUG args=kadmin.local -q addprinc -randkey ldap/vm-001.ipa.com@IPA.COM -x ipa-setup-override-restrictions
2013-05-22T08:32:25Z DEBUG Process finished, return code=1
2013-05-22T08:32:25Z DEBUG stdout=
2013-05-22T08:32:25Z DEBUG stderr=kadmin.local: Credential cache directory /run/user/0/krb5cc does not exist while opening default credentials cache

Version-Release number of selected component (if applicable):

[tbabej@vm-001 labtool]$ rpm -qa | grep krb
krb5-server-1.11.2-5.fc19.x86_64
krb5-workstation-1.11.2-5.fc19.x86_64
krb5-pkinit-1.11.2-5.fc19.x86_64
krb5-devel-1.11.2-5.fc19.x86_64
python-krbV-1.0.90-6.fc19.x86_64
pam_krb5-2.4.5-1.fc19.x86_64
krb5-libs-1.11.2-5.fc19.x86_64

Steps to reproduce:
1. Install freeipa-server from sources
(current HEAD 89be148580169d9a8dbafa8a72f8c23034e3b601)
2. run ipa-server-install
Comment 1 Tomas Babej 2013-05-24 04:14:01 EDT
I am able to circumvent this error by downgrading to krb5-1.11.2-2 packages.
Comment 2 Nalin Dahyabhai 2013-05-24 11:24:07 EDT
1.11 will create /run/user/0/krb5cc if it doesn't exist but /run/user/0 does.  Why doesn't /run/user/0 exist?  Are you doing this via sudo or su?
Comment 3 Tomas Babej 2013-05-27 06:16:25 EDT
I can reproduce this both via sudo and su.
Comment 4 Tomas Babej 2013-05-27 06:26:24 EDT
Creating the /run/user/0 directory manually is a sufficient workaround though.
Comment 5 Ondrej Kos 2013-05-27 08:16:11 EDT
I just hit the same issue, clean installation of F19, up to date, using following packages:

freeipa-server-3.2.0-2.fc19.x86_64
krb5-server-1.11.2-6.fc19.x86_64
krb5-libs-1.11.2-6.fc19.x86_64
krb5-workstation-1.11.2-6.fc19.x86_64
pam_krb5-2.4.5-1.fc19.x86_64
krb5-pkinit-1.11.2-6.fc19.x86_64
krb5-devel-1.11.2-6.fc19.x86_64


Tomas' workaround works, but it is not the best solution, the directory should be created by kadmin, while not found.
Comment 6 Martin Kosek 2013-05-28 04:27:17 EDT
Yes, the difference is in how I access the root account. If I log to it directly, /run/user/0 exists. If I su or sudo to it, it breaks:

$ ssh vm-112.DOMAIN
mkosek@vm-112.DOMAIN's password: 
[root@vm-112 ~]# klist
klist: No credentials cache found while getting default ccache
[root@vm-112 ~]# ls /run/user/
525
[root@vm-112 ~]# kinit admin
kinit: Credential cache directory /run/user/0/krb5cc does not exist while getting default ccache
[root@vm-112 ~]# logout
mkosek@vm-112 [ ~ ]$ logout
Connection to vm-112.DOMAIN closed.

$ ssh root@vm-112.DOMAIN
Last login: Tue May 28 10:21:29 2013
[root@vm-112 ~]# klist
klist: No credentials cache found (ticket cache DIR::/run/user/0/krb5cc/tkt)
[root@vm-112 ~]# kinit admin
Password for admin@REALM: 
[root@vm-112 ~]# klist
Ticket cache: DIR::/run/user/0/krb5cc/tktat5S61
Default principal: admin@DOMAIN

Valid starting       Expires              Service principal
05/27/2013 22:24:14  05/28/2013 22:24:14  krbtgt/REALM@DOMAIN
	renew until 05/29/2013 10:24:13
Comment 7 Nalin Dahyabhai 2013-05-28 13:50:07 EDT
(In reply to Ondrej Kos from comment #5)
> Tomas' workaround works, but it is not the best solution, the directory
> should be created by kadmin, while not found.

In the general case, you really don't want random processes creating entire directory paths, since they can't know what permissions to use for intermediate parts.  It makes more sense to me to have ipa-server-install set KRB5CCNAME to some location of its own for the duration of its run.
Comment 8 Martin Kosek 2013-05-29 02:56:22 EDT
Nalin, this is not just about kadmin. The /run/user/0 directory is not created for a simple "login as normal user; sudo su -; kinit some_kerberos_user" case. See the Comment 6 for details.

I just see I deleted the actual "sudo su -" command right after
$ ssh vm-112.DOMAIN
mkosek@vm-112.DOMAIN's password: 
The rest of the test case is done with root logged in through sudo.

Anyway, I think this use case needs to be fixed as soon as possible, it is a regression. It used to work fine with Fedora 18 and krb5-libs-1.10.3-14.fc18.x86_64:

$ ssh mkosek@vm-148.DOMAIN
Last login: Tue May 28 14:53:21 2013 from 10.34.4.72
mkosek@vm-148 [ ~ ]$ sudo su -
[root@vm-148 ~]# klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
[root@vm-148 ~]# kinit admin
Password for admin@REALM: 
[root@vm-148 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@REALM

Valid starting     Expires            Service principal
05/28/13 14:54:33  05/29/13 14:54:30  krbtgt/DOMAIN@REALM
Comment 9 Nalin Dahyabhai 2013-05-29 16:32:38 EDT
(In reply to Martin Kosek from comment #8)
> Nalin, this is not just about kadmin. The /run/user/0 directory is not
> created for a simple "login as normal user; sudo su -; kinit
> some_kerberos_user" case. See the Comment 6 for details.

Yes, and the location corresponding to the user's loginuid is only created when the user logs in, or precreated for the user if the "loginctl enable-linger" command has been used for a given user.  Based on my reading of bug #965419, the lifecycle of /run/user/$LOGINUID is more or less bound to the audit session, and su and sudo have no effect on that.  I think the recommended guidance in bug #965419 was to use something like 'ssh localhost'.  There's a lengthy discussion in bug #961235 for the general case.

> I just see I deleted the actual "sudo su -" command right after
> $ ssh vm-112.DOMAIN
> mkosek@vm-112.DOMAIN's password: 
> The rest of the test case is done with root logged in through sudo.
> 
> Anyway, I think this use case needs to be fixed as soon as possible, it is a
> regression. It used to work fine with Fedora 18 and
> krb5-libs-1.10.3-14.fc18.x86_64:
> 
> $ ssh mkosek@vm-148.DOMAIN
> Last login: Tue May 28 14:53:21 2013 from 10.34.4.72
> mkosek@vm-148 [ ~ ]$ sudo su -
> [root@vm-148 ~]# klist
> klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
> [root@vm-148 ~]# kinit admin
> Password for admin@REALM: 
> [root@vm-148 ~]# klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: admin@REALM
> 
> Valid starting     Expires            Service principal
> 05/28/13 14:54:33  05/29/13 14:54:30  krbtgt/DOMAIN@REALM

Yes, we changed the hardwired default location in newer versions of the packaging.

But as far as this bug is concerned, unless having ipa-server-install leave admin credentials behind (and equally, overwriting any that I might have had before I ran it, since the default was a FILE ccache in earlier releases) is an explicit goal, having it set KRB5CCNAME to a private-for-the-duration-of-its-run location will work around this for ipa-server-install on any release.
Comment 10 Nalin Dahyabhai 2013-05-29 16:34:20 EDT
Rob, is there any chance we can have ipa-server-install use its own ccache?  Or is using the user's default ccache part of the design?
Comment 11 Rob Crittenden 2013-05-29 17:09:17 EDT
I see no problem using a private ccache for the installer.

I agree that this change in behavior is rather jarring.
Comment 12 Martin Kosek 2013-05-30 03:46:33 EDT
(In reply to Nalin Dahyabhai from comment #10)
> Rob, is there any chance we can have ipa-server-install use its own ccache? 
> Or is using the user's default ccache part of the design?

We can certainly do that. As non-existence of /run/user/0 is already dealt with in Bug 961235, I will move this bug back in FreeIPA so that we can fix the ipa-server-install.
Comment 13 Martin Kosek 2013-05-30 07:50:49 EDT
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3666
Comment 15 Fedora Update System 2013-06-07 10:36:17 EDT
freeipa-3.2.1-1.fc19, samba-4.0.6-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/freeipa-3.2.1-1.fc19,samba-4.0.6-3.fc19
Comment 16 Fedora Update System 2013-06-07 11:38:58 EDT
Package freeipa-3.2.1-1.fc19, samba-4.0.6-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing freeipa-3.2.1-1.fc19 samba-4.0.6-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10271/freeipa-3.2.1-1.fc19,samba-4.0.6-3.fc19
then log in and leave karma (feedback).
Comment 17 Fedora Update System 2013-06-14 00:48:25 EDT
freeipa-3.2.1-1.fc19, samba-4.0.6-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.