Bug 965989
| Summary: | kadmin.local fails when adding a principal in ipa-server-install | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tomas Babej <tbabej> |
| Component: | freeipa | Assignee: | Rob Crittenden <rcritten> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | abokovoy, chhudson, jhrozek, mkosek, nalin, nathaniel, okos, pviktori, rcritten, ssorce, tbabej |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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 04:48:25 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Tomas Babej
2013-05-22 09:00:07 UTC
I am able to circumvent this error by downgrading to krb5-1.11.2-2 packages. 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? I can reproduce this both via sudo and su. Creating the /run/user/0 directory manually is a sufficient workaround though. 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. 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'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 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 (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. 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'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 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 (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'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 > 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. 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? I see no problem using a private ccache for the installer. I agree that this change in behavior is rather jarring. (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. Upstream ticket: https://fedorahosted.org/freeipa/ticket/3666 Fixed upstream: master: https://fedorahosted.org/freeipa/changeset/6f51f92138ff12eff732bf028751dcfa8ef9b442 ipa-3-2: https://fedorahosted.org/freeipa/changeset/4ec1de1a65f1fabe7f5b26b4c4487deec5cea0cf 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 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). 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. |