What's the best way to debug SELinux issues on SSSD?

[Fabiano Fidêncio]

People,

I've been trying to debug a SELinux issue related to the domain
resolution order.

Basically, if there's no domain_reoslution_order set:
[root@client1 vagrant]# ssh -l admin localhost
Password:
Last login: Mon May 21 19:00:06 2018 from ::1
[admin@client1 ~]$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023

But, if domain_resolution_order is set:
[root@client1 vagrant]# ssh -l admin localhost
Password:
Last login: Mon May 21 19:30:45 2018 from ::1
[[e-mail]@client1 ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

First thing that came to my mind was to take a look at
selinux_child.logs, but it didn't give me any clue as the logs are
exactly the same for both cases:

No domain_resolution_order set:
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
(0x0400): selinux_child started.
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
(0x2000): Running with effective IDs: [0][0].
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
(0x2000): Running with real IDs [0][0].
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
(0x0400): context initialized
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
[unpack_buffer] (0x2000): seuser length: 7
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
[unpack_buffer] (0x2000): seuser: staff_u
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
[unpack_buffer] (0x2000): mls_range length: 14
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
[unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
[unpack_buffer] (0x2000): username length: 5
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
[unpack_buffer] (0x2000): username: admin
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
(0x0400): performing selinux operations
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
[seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser:
staff_u mls: s0-s0:c0.c1023
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
[pack_buffer] (0x0400): result [0]
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
[prepare_response] (0x4000): r->size: 4
(Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
(0x0400): selinux_child completed successfully

domain_resolution_order set:
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
(0x0400): selinux_child started.
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
(0x2000): Running with effective IDs: [0][0].
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
(0x2000): Running with real IDs [0][0].
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
(0x0400): context initialized
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
[unpack_buffer] (0x2000): seuser length: 7
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
[unpack_buffer] (0x2000): seuser: staff_u
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
[unpack_buffer] (0x2000): mls_range length: 14
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
[unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
[unpack_buffer] (0x2000): username length: 5
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
[unpack_buffer] (0x2000): username: admin
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
(0x0400): performing selinux operations
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
[seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser:
staff_u mls: s0-s0:c0.c1023
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
[pack_buffer] (0x0400): result [0]
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
[prepare_response] (0x4000): r->size: 4
(Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
(0x0400): selinux_child completed successfully

Taking a look at the IPA provider, logs also do like the very same:
https://paste.fedoraproject.org/paste/FKhvxyj3clzXuE5C7tMGhw (pastebin
is huge!)

Some tip on which logs I could take a look and/or part of the code I
could instrument in order to, at least, get some directions?

Thanks in advance,
--
Fabiano Fidêncio

[Jakub Hrozek]

> On 21 May 2018, at 21:39, Fabiano Fidêncio  wrote:
>
> People,
>
> I've been trying to debug a SELinux issue related to the domain
> resolution order.
>
> Basically, if there's no domain_reoslution_order set:
> [root@client1 vagrant]# ssh -l admin localhost
> Password:
> Last login: Mon May 21 19:00:06 2018 from ::1
> [admin@client1 ~]$ id -Z
> staff_u:staff_r:staff_t:s0-s0:c0.c1023
>
> But, if domain_resolution_order is set:
> [root@client1 vagrant]# ssh -l admin localhost
> Password:
> Last login: Mon May 21 19:30:45 2018 from ::1
> [[e-mail]@client1 ~]$ id -Z
> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Since sssd calls into libsemanage, then I would start with looking at the output of “semanage login -l”. Is the context after selinux_child runs to completion set for admin or [e-mail]? Maybe libsemanage canonicalizes the name or UID with getpnam/uid and therefore uses the qualified name but because the provider has no sense of the domain_resolution_order, it calls sss_set_seuser() with the shortname?

Looking at whether we call sss_set_seuser() with the correct parameters might give some hint as well.
> First thing that came to my mind was to take a look at
> selinux_child.logs, but it didn't give me any clue as the logs are
> exactly the same for both cases:
>
> No domain_resolution_order set:
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> (0x0400): selinux_child started.
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> (0x2000): Running with effective IDs: [0][0].
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> (0x2000): Running with real IDs [0][0].
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> (0x0400): context initialized
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> [unpack_buffer] (0x2000): seuser length: 7
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> [unpack_buffer] (0x2000): seuser: staff_u
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> [unpack_buffer] (0x2000): mls_range length: 14
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> [unpack_buffer] (0x2000): username length: 5
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> [unpack_buffer] (0x2000): username: admin
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> (0x0400): performing selinux operations
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> [seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser:
> staff_u mls: s0-s0:c0.c1023
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> [pack_buffer] (0x0400): result [0]
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> [prepare_response] (0x4000): r->size: 4
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> (0x0400): selinux_child completed successfully
>
> domain_resolution_order set:
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> (0x0400): selinux_child started.
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> (0x2000): Running with effective IDs: [0][0].
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> (0x2000): Running with real IDs [0][0].
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> (0x0400): context initialized
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> [unpack_buffer] (0x2000): seuser length: 7
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> [unpack_buffer] (0x2000): seuser: staff_u
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> [unpack_buffer] (0x2000): mls_range length: 14
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> [unpack_buffer] (0x2000): username length: 5
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> [unpack_buffer] (0x2000): username: admin
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> (0x0400): performing selinux operations
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> [seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser:
> staff_u mls: s0-s0:c0.c1023
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> [pack_buffer] (0x0400): result [0]
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> [prepare_response] (0x4000): r->size: 4
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> (0x0400): selinux_child completed successfully
>
> Taking a look at the IPA provider, logs also do like the very same:
> https://paste.fedoraproject.org/paste/FKhvxyj3clzXuE5C7tMGhw (pastebin
> is huge!)
>
> Some tip on which logs I could take a look and/or part of the code I
> could instrument in order to, at least, get some directions?
> Thanks in advance,
>
> Fabiano Fidêncio
> _______________________________________________
> sssd-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

[Fabiano Fidêncio]

On Mon, May 21, 2018 at 10:32 PM, Jakub Hrozek  wrote:
> > On 21 May 2018, at 21:39, Fabiano Fidêncio  wrote:
> >
> > People,
> >
> > I've been trying to debug a SELinux issue related to the domain
> > resolution order.
> >
> > Basically, if there's no domain_reoslution_order set:
> > [root@client1 vagrant]# ssh -l admin localhost
> > Password:
> > Last login: Mon May 21 19:00:06 2018 from ::1
> > [admin@client1 ~]$ id -Z
> > staff_u:staff_r:staff_t:s0-s0:c0.c1023
> >
> > But, if domain_resolution_order is set:
> > [root@client1 vagrant]# ssh -l admin localhost
> > Password:
> > Last login: Mon May 21 19:30:45 2018 from ::1
> > [[e-mail]@client1 ~]$ id -Z
> > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>
> Since sssd calls into libsemanage, then I would start with looking at the output of “semanage login -l”.

You gave me this tip before, I did test it but I forgot to add details
about it :-/

The output is basically the same with or without domain_resolution_order set:

[root@client1 x86_64]# cat /etc/sssd/sssd.conf | grep domain_resolution_order
domain_resolution_order = foo
[root@client1 x86_64]# systemctl restart sssd
[root@client1 x86_64]# semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         s0-s0:c0.c1023       *
admin                staff_u              s0-s0:c0.c1023       *
root                 unconfined_u         s0-s0:c0.c1023       *

[root@client1 x86_64]# vim /etc/sssd/sssd.conf
[root@client1 x86_64]# cat /etc/sssd/sssd.conf | grep domain_resolution_order
#domain_resolution_order = foo
[root@client1 x86_64]# systemctl restart sssd
[root@client1 x86_64]# semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         s0-s0:c0.c1023       *
admin                staff_u              s0-s0:c0.c1023       *
root                 unconfined_u         s0-s0:c0.c1023       *
> Is the context after selinux_child runs to completion set for admin or [e-mail]?

In the selinux_child.log I can only see:
[[sssd[selinux_child[18149]]]] [unpack_buffer] (0x2000): username: admin

And it happens for both cases, with or without domain_resolution_order
being used.
> Maybe libsemanage canonicalizes the name or UID with getpnam/uid and therefore uses the qualified name but because the provider has no sense of the domain_resolution_order, it calls sss_set_seuser() with the shortname?

That's a good question. sss_set_seuser() hasn't been called, at all.
> Looking at whether we call sss_set_seuser() with the correct parameters might give some hint as well.
> > First thing that came to my mind was to take a look at
> > selinux_child.logs, but it didn't give me any clue as the logs are
> > exactly the same for both cases:
> >
> > No domain_resolution_order set:
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> > (0x0400): selinux_child started.
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> > (0x2000): Running with effective IDs: [0][0].
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> > (0x2000): Running with real IDs [0][0].
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> > (0x0400): context initialized
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > [unpack_buffer] (0x2000): seuser length: 7
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > [unpack_buffer] (0x2000): seuser: staff_u
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > [unpack_buffer] (0x2000): mls_range length: 14
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > [unpack_buffer] (0x2000): username length: 5
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > [unpack_buffer] (0x2000): username: admin
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> > (0x0400): performing selinux operations
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > [seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser:
> > staff_u mls: s0-s0:c0.c1023
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > [pack_buffer] (0x0400): result [0]
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > [prepare_response] (0x4000): r->size: 4
> > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> > (0x0400): selinux_child completed successfully
> >
> > domain_resolution_order set:
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> > (0x0400): selinux_child started.
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> > (0x2000): Running with effective IDs: [0][0].
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> > (0x2000): Running with real IDs [0][0].
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> > (0x0400): context initialized
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > [unpack_buffer] (0x2000): seuser length: 7
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > [unpack_buffer] (0x2000): seuser: staff_u
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > [unpack_buffer] (0x2000): mls_range length: 14
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > [unpack_buffer] (0x2000): username length: 5
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > [unpack_buffer] (0x2000): username: admin
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> > (0x0400): performing selinux operations
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > [seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser:
> > staff_u mls: s0-s0:c0.c1023
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > [pack_buffer] (0x0400): result [0]
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > [prepare_response] (0x4000): r->size: 4
> > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> > (0x0400): selinux_child completed successfully
> >
> > Taking a look at the IPA provider, logs also do like the very same:
> > https://paste.fedoraproject.org/paste/FKhvxyj3clzXuE5C7tMGhw (pastebin
> > is huge!)
> >
> > Some tip on which logs I could take a look and/or part of the code I
> > could instrument in order to, at least, get some directions?
> > Thanks in advance,
> >
> > Fabiano Fidêncio
> > _______________________________________________
> > sssd-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
>
> sssd-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

[Jakub Hrozek]

> On 21 May 2018, at 23:58, Fabiano Fidêncio  wrote:
>
> On Mon, May 21, 2018 at 10:32 PM, Jakub Hrozek  wrote:
> > > On 21 May 2018, at 21:39, Fabiano Fidêncio  wrote:
> > >
> > > People,
> > >
> > > I've been trying to debug a SELinux issue related to the domain
> > > resolution order.
> > >
> > > Basically, if there's no domain_reoslution_order set:
> > > [root@client1 vagrant]# ssh -l admin localhost
> > > Password:
> > > Last login: Mon May 21 19:00:06 2018 from ::1
> > > [admin@client1 ~]$ id -Z
> > > staff_u:staff_r:staff_t:s0-s0:c0.c1023
> > >
> > > But, if domain_resolution_order is set:
> > > [root@client1 vagrant]# ssh -l admin localhost
> > > Password:
> > > Last login: Mon May 21 19:30:45 2018 from ::1
> > > [[e-mail]@client1 ~]$ id -Z
> > > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> >
> > Since sssd calls into libsemanage, then I would start with looking at the output of “semanage login -l”.
>
> You gave me this tip before, I did test it but I forgot to add details
> about it :-/
>
> The output is basically the same with or without domain_resolution_order set:
>
> [root@client1 x86_64]# cat /etc/sssd/sssd.conf | grep domain_resolution_order
> domain_resolution_order = foo
> [root@client1 x86_64]# systemctl restart sssd
> [root@client1 x86_64]# semanage login -l
>
> Login Name           SELinux User         MLS/MCS Range        Service
>
> __default__          unconfined_u         s0-s0:c0.c1023       *
> admin                staff_u              s0-s0:c0.c1023       *
> root                 unconfined_u         s0-s0:c0.c1023       *
>
> [root@client1 x86_64]# vim /etc/sssd/sssd.conf
> [root@client1 x86_64]# cat /etc/sssd/sssd.conf | grep domain_resolution_order
> #domain_resolution_order = foo
> [root@client1 x86_64]# systemctl restart sssd
> [root@client1 x86_64]# semanage login -l
>
> Login Name           SELinux User         MLS/MCS Range        Service
>
> __default__          unconfined_u         s0-s0:c0.c1023       *
> admin                staff_u              s0-s0:c0.c1023       *
> root                 unconfined_u         s0-s0:c0.c1023       *
> > Is the context after selinux_child runs to completion set for admin or [e-mail]?
>
> In the selinux_child.log I can only see:
> [[sssd[selinux_child[18149]]]] [unpack_buffer] (0x2000): username: admin

Right and looking at the selinux_child code, we /try/ to format the name to the output format that getpwnam would return for precisely this reason (see selinux_child_setup). but because we don’t know about the extra qualification that the domain suffix causes, we fail to qualify the name.

And looking at the pam_selinux code, it does canonicalize the username with getpwnam:

496   if (!(username = get_item(pamh, PAM_USER))) {
497     pam_syslog(pamh, LOG_ERR, "Cannot obtain the user name");
498     return PAM_USER_UNKNOWN;
499   }
500
501   if ((pwd = pam_modutil_getpwnam(pamh, username)) != NULL) {
502     username = pwd->pw_name;
503   } /* ignore error and keep using original username */
504

So selinux_child sets the context to admin, but pam_selinux checks the context of admin@domain because that’s what getpwnam(“admin”) returns.
> And it happens for both cases, with or without domain_resolution_order
> being used.
> > Maybe libsemanage canonicalizes the name or UID with getpnam/uid and therefore uses the qualified name but because the provider has no sense of the domain_resolution_order, it calls sss_set_seuser() with the shortname?
>
> That's a good question. sss_set_seuser() hasn't been called, at all.

There is an optimization that first queries the semanage back end and if the context is already set, then sss_set_seuser() is just skipped. Setting the context is not/was not a cheap operation.
> > Looking at whether we call sss_set_seuser() with the correct parameters might give some hint as well.
> > > First thing that came to my mind was to take a look at
> > > selinux_child.logs, but it didn't give me any clue as the logs are
> > > exactly the same for both cases:
> > >
> > > No domain_resolution_order set:
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> > > (0x0400): selinux_child started.
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> > > (0x2000): Running with effective IDs: [0][0].
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> > > (0x2000): Running with real IDs [0][0].
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> > > (0x0400): context initialized
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > > [unpack_buffer] (0x2000): seuser length: 7
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > > [unpack_buffer] (0x2000): seuser: staff_u
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > > [unpack_buffer] (0x2000): mls_range length: 14
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > > [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > > [unpack_buffer] (0x2000): username length: 5
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > > [unpack_buffer] (0x2000): username: admin
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> > > (0x0400): performing selinux operations
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > > [seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser:
> > > staff_u mls: s0-s0:c0.c1023
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > > [pack_buffer] (0x0400): result [0]
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]]
> > > [prepare_response] (0x4000): r->size: 4
> > > (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main]
> > > (0x0400): selinux_child completed successfully
> > >
> > > domain_resolution_order set:
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> > > (0x0400): selinux_child started.
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> > > (0x2000): Running with effective IDs: [0][0].
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> > > (0x2000): Running with real IDs [0][0].
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> > > (0x0400): context initialized
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > > [unpack_buffer] (0x2000): seuser length: 7
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > > [unpack_buffer] (0x2000): seuser: staff_u
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > > [unpack_buffer] (0x2000): mls_range length: 14
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > > [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > > [unpack_buffer] (0x2000): username length: 5
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > > [unpack_buffer] (0x2000): username: admin
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> > > (0x0400): performing selinux operations
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > > [seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser:
> > > staff_u mls: s0-s0:c0.c1023
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > > [pack_buffer] (0x0400): result [0]
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]]
> > > [prepare_response] (0x4000): r->size: 4
> > > (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main]
> > > (0x0400): selinux_child completed successfully
> > >
> > > Taking a look at the IPA provider, logs also do like the very same:
> > > https://paste.fedoraproject.org/paste/FKhvxyj3clzXuE5C7tMGhw (pastebin
> > > is huge!)
> > >
> > > Some tip on which logs I could take a look and/or part of the code I
> > > could instrument in order to, at least, get some directions?
> > > Thanks in advance,
> > >
> > > Fabiano Fidêncio
> > > _______________________________________________
> > > sssd-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> >
> > sssd-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
>
> sssd-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....