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 _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
