On (15/02/18 16:40), Jakub Hrozek wrote:
The selinux_child failed:
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961]]]] [seuser_needs_update] (0x2000):
getseuserbyname: ret: 0 seuser: unconfined_u mls: unknown
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961]]]] [libsemanage] (0x0020): could
not cache policy database
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961]]]] [libsemanage] (0x0020): could
not cache join database
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961]]]] [libsemanage] (0x0020): could
not enter read-only section
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961]]]] [libsemanage] (0x0020): Error
while reading kernel policy from /var/lib/selinux/targeted/active/policy.linked.
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961]]]] [set_seuser] (0x0020): Cannot
commit SELinux transaction
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961]]]] [main] (0x0020): Cannot set
SELinux login context.
(Thu Feb 15 11:18:05 2018) [[sssd[selinux_child[20961]]]] [main] (0x0020): selinux_child
failed!
What is 'sestatus' telling you? If you don't use the SELInux login mapping,
you can set selinux_provider=none to work around tihs.
That workaround should not be required.
It might be related to
https://pagure.io/SSSD/sssd/issue/3618
And backported to sssd-1.16.0-6.fc27 which is already in stable on f27
for 3 days.
Does it fails even with sssd-1.16.0-6.fc27 ?
BTW If directory /var/lib/selinux/targeted/active/ is in weird state
then you might call "semodule --build" and it might repair it.
But you should not get to such state with sssd-1.16.0-6.fc27
LS