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