Bug 1815877

Summary:	authselect fails to select sssd profile in OpenQA tests
Product:	[Fedora] Fedora	Reporter:	Alexander Bokovoy <abokovoy>
Component:	authselect	Assignee:	Pavel Březina <pbrezina>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	32	CC:	awilliam, cheimes, jhrozek, pbrezina
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-04-22 15:24:49 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 Alexander Bokovoy 2020-03-22 11:22:05 UTC

This looks like a reproducible problem in multiple OpenQA tests in Fedora 32, resulting in a failure to enroll a client to FreeIPA. For example, https://openqa.fedoraproject.org/tests/552738 shows in ipa-client-install.log:

2020-03-21T23:18:34Z DEBUG Current configuration not managed by authselect
2020-03-21T23:18:34Z WARNING WARNING: The configuration pre-client installation is not managed by authselect and cannot be backed up. Uninstallation may not be able to revert to the original state.
2020-03-21T23:18:34Z DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
2020-03-21T23:18:34Z DEBUG Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state'
2020-03-21T23:18:34Z DEBUG Starting external process
2020-03-21T23:18:34Z DEBUG args=['/usr/bin/authselect', 'select', 'sssd', 'with-mkhomedir', 'with-sudo', '--force']
2020-03-21T23:18:34Z DEBUG Process finished, return code=2
2020-03-21T23:18:34Z DEBUG stdout=Backup stored at /var/lib/authselect/backups/2020-03-21-23-18-34.NqHCZP
  
2020-03-21T23:18:34Z DEBUG stderr=[error] Unable to create selabel context [2]: No such file or directory
[error] Unable to get default selinux context for [/etc/dconf/db/distro.d/20-authselect] [2]: No such file or directory!
[error] Unable to create selabel context [2]: No such file or directory
[error] Unable to get default selinux context for [/etc/dconf/db/distro.d/locks/20-authselect] [2]: No such file or directory!
[error] Unable to create selabel context [2]: No such file or directory
[error] Unable to get default selinux context for [/var/lib/authselect/system-auth] [2]: No such file or directory!
[error] Unable to create temporary file for [/var/lib/authselect/system-auth] [2]: No such file or directory
[error] Unable to write temporary file [/var/lib/authselect/system-auth] [2]: No such file or directory
[error] Unable to write generated system files [2]: No such file or directory
[error] Unable to activate profile [sssd] [2]: No such file or directory
Unable to activate profile [2]: No such file or directory

Comment 1 Alexander Bokovoy 2020-03-22 11:24:05 UTC

The test is triggered by a new FreeIPA update (https://bodhi.fedoraproject.org/updates/FEDORA-2020-e3a79248dc) which introduces SELinux policy in freeipa-selinux package. However, I was not able to find any authselect-related SELinux policy definition anywhere.

Comment 2 Adam Williamson 2020-03-23 00:06:45 UTC

The test is only failing on that update, not updates before or after it. So it seems like introducing the FreeIPA selinux policy really triggers this somehow. I'd guess it's something like, with the policy in place, something that used to be unconfined is now confined, and that results in these denials?

Comment 3 Christian Heimes 2020-03-23 08:02:04 UTC

The first error message "Unable to create selabel context" is coming from authselect [1]. The function call selabel_open(SELABEL_CTX_FILE, NULL, 0) [2] is failing. This could also be a problem with SELinux userspace library.

[1] https://github.com/authselect/authselect/blob/478ec8c356d6f0162f8a954b426b1eaeee29f3e0/src/lib/util/selinux.c#L35-L48
[2] https://linux.die.net/man/3/selabel_open

Comment 4 Christian Heimes 2020-03-23 09:23:34 UTC

I cannot reproduce the problem either. realm join works fine for me on a recently updated F32 machine.

Comment 5 Pavel Březina 2020-03-23 15:01:44 UTC

Authselect does not define any selinux policy, it is just trying to set the right default context for newly created files - they are first written as temporary files and then moved to their correct location so authselect needs to make sure they are created with right context.

Is there any way for FreeIPA selinux policy to interfere with selabel_open()?

Comment 6 Adam Williamson 2020-03-23 16:05:31 UTC

Christian: did you ensure the packages from FEDORA-2020-e3a79248dc were used in your test? That is where the problem exists.

Comment 7 Pavel Březina 2020-04-22 11:04:10 UTC

Are there any news on thig bug? Is it still happening?

Comment 8 Adam Williamson 2020-04-22 15:24:49 UTC

from the update comments it looks like this was fixed somehow in freeipa 4.8.6. FreeIPA tests are passing in F32 and Rawhide ATM so I think we can close this.