Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionBrian J. Murrell
2015-04-09 16:54:18 UTC
Opening this bug since it happens on RHEL 6.6 also.
+++ This bug was initially created as a clone of Bug #1161592 +++
Description of problem:
ipa-server-install fails on configuaration of kadmin:
systemctl start kadmin.service
errors out.
Version-Release number of selected component (if applicable):
freeipa-server-4.1.1-1
krb5-server-1.12.2-8.fc21.x86_64
selinux-policy-3.13.1-92.fc21.noarch
How reproducible:
Always
Steps to Reproduce:
1. run ipa-server-install
or then just
1. systemctl start kadmin.service
Actual results:
ipa-server-install fails on configuration of kadmin
Expected results:
ipa-server-install finishes successfully
Additional info:
found 2 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------
SELinux is preventing kadmind from unlink access on the file kadmin_0.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that kadmind should be allowed unlink access on the kadmin_0 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep kadmind /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:kadmind_t:s0
Target Context system_u:object_r:tmp_t:s0
Target Objects kadmin_0 [ file ]
Source kadmind
Source Path kadmind
Port <Unknown>
Host <Unknown>
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.13.1-92.fc21.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name obfuscated
Platform Linux obfuscated
3.16.3-300.fc21.x86_64 #1 SMP Wed Sep 17 20:54:02
UTC 2014 x86_64 x86_64
Alert Count 8
First Seen 2014-11-07 12:14:58 CET
Last Seen 2014-11-07 12:14:58 CET
Local ID 8965a9af-8310-43d7-94ff-d63c89029193
Raw Audit Messages
type=AVC msg=audit(1415358898.900:118): avc: denied { unlink } for pid=2706 comm="kadmind" name="kadmin_0" dev="dm-0" ino=411321 scontext=system_u:system_r:kadmind_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file permissive=0
Hash: kadmind,kadmind_t,tmp_t,file,unlink
--------------------------------------------------------------------------------
SELinux is preventing kadmind from write access on the file kadmin_0.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that kadmind should be allowed write access on the kadmin_0 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep kadmind /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:kadmind_t:s0
Target Context system_u:object_r:tmp_t:s0
Target Objects kadmin_0 [ file ]
Source kadmind
Source Path kadmind
Port <Unknown>
Host <Unknown>
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.13.1-92.fc21.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name obfuscated
Platform Linux obfuscated
3.16.3-300.fc21.x86_64 #1 SMP Wed Sep 17 20:54:02
UTC 2014 x86_64 x86_64
Alert Count 8
First Seen 2014-11-07 12:14:58 CET
Last Seen 2014-11-07 12:14:58 CET
Local ID d985fe2c-dded-423d-af45-31e3e220085a
Raw Audit Messages
type=AVC msg=audit(1415358898.905:123): avc: denied { write } for pid=2706 comm="kadmind" name="kadmin_0" dev="dm-0" ino=411321 scontext=system_u:system_r:kadmind_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file permissive=0
Hash: kadmind,kadmind_t,tmp_t,file,write
--- Additional comment from Martin Kosek on 2014-11-07 07:52:50 EST ---
This is Fedora 21 Final blocker as it blocks FreeIPA server installation, Stephen is already in copy.
--- Additional comment from Fedora Blocker Bugs Application on 2014-11-07 07:58:08 EST ---
Proposed as a Blocker for 21-final by Fedora user sgallagh using the blocker tracking app because:
Proposed criterion: https://lists.fedoraproject.org/pipermail/server/2014-November/001551.html
From Alpha Criteria:
"Unless explicitly specified otherwise, after system installation SELinux must be enabled and in enforcing mode"
--- Additional comment from Miroslav Grepl on 2014-11-07 08:25:07 EST ---
Could you confirm it happens also if you remove /tmp/kadmin_0 a re-test it with ipa-server-install?
--- Additional comment from Miroslav Grepl on 2014-11-07 08:27:12 EST ---
Something created "kadmin_0" in /tmp with tmp_t. Have you ever run in permissive mode?
--- Additional comment from Nalin Dahyabhai on 2014-11-07 08:48:07 EST ---
More likely it's kadmind's replay cache, which would be in /var/tmp, and would usually be labeled kadmind_tmp_t when it's created by kadmind.
--- Additional comment from Petr Vobornik on 2014-11-07 09:46:54 EST ---
removal of /var/tmp/kadmin_0 fixes the issue and FreeIPA is successfully installed. kadmin_0 is recreated with correct kadmind_tmp_t label.
Seems that comment 4 is the source of the error. Therefore probably NOT A BUG.
Cause of the mistake:
* server was initially installed with old SELinux Policy.
* installation was run in permissive mode
* SELinux Policy was updated
* installation was run in enforcing mode
On new clear vm with updated policy and in enforcing mode the installation succeeds.
Sorry for noise.
--- Additional comment from Stephen Gallagher on 2014-11-07 09:49:49 EST ---
OK, closing as NOTABUG. I will reopen it if it reappears during testing.
Thanks for the quick response, folks!
--- Additional comment from Miroslav Grepl on 2014-11-07 09:51:26 EST ---
Of course I meant /vat/tmp//kadmin_0.
Basically this was probably caused by a combination of these reasons.
--- Additional comment from Brian J. Murrell on 2015-03-26 11:53:18 EDT ---
I hit this issue on RHEL 6.6 also. It happened to me because I switched a system from selinux disabled to selinux enforcing. But I did invoke an autorelabel between those two states.
It seems like a bug that /var/tmp/kadmin_0 can be left around and not relabeled by an autolabel.
Could we get this reopened as such?
--- Additional comment from Miroslav Grepl on 2015-04-09 12:45:33 EDT ---
(In reply to Brian J. Murrell from comment #9)
> I hit this issue on RHEL 6.6 also. It happened to me because I switched a
> system from selinux disabled to selinux enforcing. But I did invoke an
> autorelabel between those two states.
>
> It seems like a bug that /var/tmp/kadmin_0 can be left around and not
> relabeled by an autolabel.
>
> Could we get this reopened as such?
If so, please open a new RHEL6 bug.
It happened to me because I switched a system from selinux disabled to selinux enforcing. But I did invoke an autorelabel between those two states.
It seems like a bug that /var/tmp/kadmin_0 can be left around and not relabeled by an autolabel.
I talked to pkis, who is a kerberos QE, and he told me that following file will most likely suffer from the same problem:
# matchpathcon /var/tmp/kiprop_0
/var/tmp/kiprop_0 <<none>>
#
(In reply to Milos Malik from comment #5)
> I talked to pkis, who is a kerberos QE, and he told me that following file
> will most likely suffer from the same problem:
>
> # matchpathcon /var/tmp/kiprop_0
> /var/tmp/kiprop_0 <<none>>
> #
And should we use also kadmind_tmp_t labeling for it?
It would be better to label the /var/tmp/kiprop_0 as krb5kdc_tmp_t, because:
# sesearch -s kpropd_t -t tmp_t -T
Found 2 semantic te rules:
type_transition kpropd_t tmp_t : file krb5kdc_tmp_t;
type_transition kpropd_t tmp_t : dir krb5kdc_tmp_t;
#
commit 2d83c73a710ba8fe59e62cdea02446b4c2071d1e
Author: Miroslav Grepl <mgrepl>
Date: Tue May 12 09:00:46 2015 +0200
Add labeling for /var/tmp/kadmin_0 and /var/tmp/kiprop_0.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2015-1375.html