[Freeipa-users] SUDO does not always works on first try

[Jakub Hrozek]

On Fri, Oct 09, 2015 at 11:04:15AM +0000, Zoske, Fabian wrote:
> Hi Jakub,
> 
> I increased the log level in every SSSD section to 6 and got following output, hope that helps.
> 
> KRB5_CHILD.LOG: https://s.mit42.de/IR6tu

All is OK here..

> 
> SSSD_SUDO.LOG (two tries are logged in it): https://s.mit42.de/WF1Jl

So the interesting part is that the first try doesn't match any rules
for the user:
    (Fri Oct  9 12:24:09 2015) [sssd[sudo]] [sysdb_search_group_by_gid]
    (0x0400): No such entry
    (Fri Oct  9 12:24:09 2015) [sssd[sudo]]
    [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
    [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=f.zoske at de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-administrators at de.eu.local)(sudoUser=%domänen-benutzer at de.eu.local)(sudoUser=+*)))]
    (Fri Oct  9 12:24:09 2015) [sssd[sudo]]
    [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for
    [f.zoske at de.eu.local]

While the second does:
    (Fri Oct  9 12:24:14 2015) [sssd[sudo]]
    [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
    [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=f.zoske at de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-administrators at de.eu.local)(sudoUser=%domänen-benutzer at de.eu.local)(sudoUser=%admins)(sudoUser=%ug_freeipa-administrators_int)(sudoUser=+*)))]
    (Fri Oct  9 12:24:14 2015) [sssd[sudo]]
    [sudosrv_get_sudorules_from_cache] (0x0400): Returning 2 rules for
    [f.zoske at de.eu.local]

It would be interesting to see the dump of the cache from when 0 rules
are returned. I suspect the user's membership wouldn't be correct, which
might be because of the bug I linked earlier.

> 
> SSSD_IPA-LX.COM: https://s.mit42.de/frBvx

There are some failures here:
(Fri Oct  9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_send]
(0x0400): Executing extended operation
(Fri Oct  9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_done]
(0x0400): ldap_extended_operation result: No such object(32), (null)
(Fri Oct  9 12:24:19 2015) [sssd[be[ipa-lx.com]]]
[ipa_s2n_get_user_done] (0x0040): s2n exop request failed.
(Fri Oct  9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [acctinfo_callback]
(0x0100): Request processed. Returned 3,1432158221,Account info lookup
failed
(Fri Oct  9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [be_get_account_info]
(0x0100): Got request for [4097][1][name=*]
(Fri Oct  9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [be_req_set_domain]
(0x0400): Changing request domain from [ipa-lx.com] to [de.eu.local]
(Fri Oct  9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_send]
(0x0400): Executing extended operation
(Fri Oct  9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_done]
(0x0400): ldap_extended_operation result: No such object(32), (null)

But I think this is a really minor bug we fixed later where we marked
requests as failed if they simply didn't find anything. If this works
without issues:
    $ sss_cache -u f.zoske at de.eu.local
    $ getent passwd f.zoske at de.eu.local

Then you can ignore those..