<div>On 09/14/2015 03:08 PM, Pavel Březina wrote:
<blockquote cite="mid:55F6C6BB.1040902@redhat.com" type="cite">On 09/11/2015 02:40 PM, Molnár Domokos wrote:
<blockquote type="cite">Full log attached.<br />
"Molnár Domokos" <kretebe@freemail.hu> írta:<br />
<br />
<br />
    "Pavel Březina" <pbrezina@redhat.com> írta:<br />
<br />
        On 09/09/2015 09:31 PM, Molnár Domokos wrote:<br />
         > I have a working IPA server and a working client config on an OpenSuse<br />
         > 13.2 with the following versions:<br />
         > nappali:~ # rpm -qa |grep sssd<br />
         > sssd-tools-1.12.2-3.4.1.i586<br />
         > sssd-krb5-1.12.2-3.4.1.i586<br />
         > python-sssd-config-1.12.2-3.4.1.i586<br />
         > sssd-ipa-1.12.2-3.4.1.i586<br />
         > sssd-1.12.2-3.4.1.i586<br />
         > sssd-dbus-1.12.2-3.4.1.i586<br />
         > sssd-krb5-common-1.12.2-3.4.1.i586<br />
         > sssd-ldap-1.12.2-3.4.1.i586<br />
         > sssd is confihured for nss, pam, sudo<br />
         > There is a test sudo rule defined in the ipa server, which applies to<br />
         > user "doma".  However when the user tries to use sudo the rule does not<br />
         > work.<br />
         > doma@nappali:/home/doma> sudo ls<br />
         > doma's password:<br />
         > doma is not allowed to run sudo on nappali.  This incident will be reported.<br />
         > The corresponding log in the sssd_sudo.log is this:<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):<br />
         > Received client version [1].<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):<br />
         > Offered version [1].<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]<br />
         > (0x0200): name 'doma' matched without domain, user is doma<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]<br />
         > (0x0200): name 'doma' matched without domain, user is doma<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]<br />
         > (0x0200): Requesting default options for [doma] from [<ALL>]<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):<br />
         > Requesting info about [doma@szilva]<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]<br />
         > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with<br />
         > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]<br />
         > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with<br />
         > [(&(objectClass=sudoRule)(|(name=defaults)))]<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]<br />
         > (0x0200): name 'doma' matched without domain, user is doma<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]<br />
         > (0x0200): name 'doma' matched without domain, user is doma<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]<br />
         > (0x0200): Requesting rules for [doma] from [<ALL>]<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):<br />
         > Requesting info about [doma@szilva]<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]<br />
         > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with<br />
         > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]<br />
         > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]<br />
         > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with<br />
         > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]<br />
         > (Wed Sep  9 21:25:30 2015) [sssd[sudo]] [client_recv] (0x0200): Client<br />
         > disconnected!<br />
         > This seems perfectly OK with one exception. The query against the sysdb<br />
         > does not find the entry. This is strange because the entry is there.<br />
         > Log in sssd.log:<br />
         > (Wed Sep  2 08:52:13 2015) [sssd] [sysdb_domain_init_internal] (0x0200):<br />
         > DB File for szilva: /var/lib/sss/db/cache_szilva.ldb<br />
         > So we know that the sysdb is /var/lib/sss/db/cache_szilva.ldb<br />
         > Running the exact same query seen above in the sssd_sudo.log against the<br />
         > db returns:<br />
         > ldbsearch -H /var/lib/sss/db/cache_szilva.ldb<br />
         > "(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))"<br />
         > asq: Unable to register control with rootdse!<br />
         > # record 1<br />
         > dn: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb<br />
         > cn: Doma_ls<br />
         > dataExpireTimestamp: 1441830262<br />
         > entryUSN: 20521<br />
         > name: Doma_ls<br />
         > objectClass: sudoRule<br />
         > originalDN: cn=Doma_ls,ou=sudoers,dc=szilva<br />
         > sudoCommand: ls<br />
         > sudoHost: nappali.szilva<br />
         > sudoRunAsGroup: ALL<br />
         > sudoRunAsUser: ALL<br />
         > sudoUser: doma<br />
         > distinguishedName: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb<br />
         > # returned 1 records<br />
         > # 1 entries<br />
         > # 0 referrals<br />
         > This confirms that the entry is indeed there in the db. Why is it found<br />
         > with ldbsearch and why does sssd_sudo not find it?<br />
         > I am pretty much stuck with this one. Anyone has an idea?<br />
         ><br />
         ><br />
        Hi,<br />
        this is strange. Can you provide the logs with debug level set to 0x3ff0<br />
<br />
        please? Can you also send it as an attachment? Thanks!<br />
<br />
    Sure. Here it is. Now I can see that the rule is returned. The<br />
    question is why the rule does not match. Anyway much better :)</blockquote>
<br />
Hi, thanks for the logs. Since the rule is returned, we will get more information from sudo logs. Can you please enable sudo logging by putting the following line into /etc/sudo.conf?<br />
<br />
Debug sudo /var/log/sudo_debug all@trace<br />
<br />
Run sudo and send us /var/log/sudo_debug? Thanks</blockquote>
<br />
Thanks for the tip with the proper debug syntax - I was unable to get a single log item out of sudo before.<br />
<br />
I think I have found something. This is the relevant part of the output of all@debug (you need this not trace I think):<br />
<br />
Sep 14 22:13:39 sudo[2314]   username=doma<br />
Sep 14 22:13:39 sudo[2314] domainname=NULL<br />
Sep 14 22:13:39 sudo[2314] state |= USERMATCH<br />
Sep 14 22:13:39 sudo[2314] Received 1 rule(s)<br />
Sep 14 22:13:39 sudo[2314] -> sudo_sss_filter_result @ ./sssd.c:175<br />
Sep 14 22:13:39 sudo[2314] in_res=0xb7c9c1b8, count=1, act=INCLUDE<br />
Sep 14 22:13:39 sudo[2314] emalloc: cnt=1<br />
Sep 14 22:13:39 sudo[2314] -> sudo_sss_result_filterp @ ./sssd.c:648<br />
Sep 14 22:13:39 sudo[2314] -> sudo_sss_check_host @ ./sssd.c:556<br />
Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva<br />
Sep 14 22:13:39 sudo[2314] -> addr_matches @ ./match_addr.c:206<br />
Sep 14 22:13:39 sudo[2314] -> addr_matches_if @ ./match_addr.c:61<br />
Sep 14 22:13:39 sudo[2314] <- addr_matches_if @ ./match_addr.c:71 := false<br />
Sep 14 22:13:39 sudo[2314] IP address nappali.szilva matches local host: false @ addr_matches() ./match_addr.c:217<br />
Sep 14 22:13:39 sudo[2314] <- addr_matches @ ./match_addr.c:218 := false<br />
Sep 14 22:13:39 sudo[2314] -> netgr_matches @ ./match.c:941<br />
Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading '+'<br />
Sep 14 22:13:39 sudo[2314] <- netgr_matches @ ./match.c:953 := false<br />
Sep 14 22:13:39 sudo[2314] -> hostname_matches @ ./match.c:776<br />
<font color="#cc0000">Sep 14 22:13:39 sudo[2314] host nappali matches sudoers pattern nappali.szilva: false @ hostname_matches() ./match.c:788</font><br />
Sep 14 22:13:39 sudo[2314] <- hostname_matches @ ./match.c:789 := false<br />
Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost 'nappali.szilva' ... not<br />
Sep 14 22:13:39 sudo[2314] <- sudo_sss_check_host @ ./sssd.c:591 := false<br />
Sep 14 22:13:39 sudo[2314] <- sudo_sss_result_filterp @ ./sssd.c:654 := 0<br />
Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1 -> 0)<br />
Sep 14 22:13:39 sudo[2314] <- sudo_sss_filter_result @ ./sssd.c:221 := 0xb7c9e410<br />
Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) => f_sss_result=(0xb7c9e410, 0)<br />
Sep 14 22:13:39 sudo[2314] <- sudo_sss_result_get @ ./sssd.c:728 := 0xb7c9e410<br />
Sep 14 22:13:39 sudo[2314] searching SSSD/LDAP for sudoers entries<br />
Sep 14 22:13:39 sudo[2314] Done with LDAP searches<br />
<br />
<br />
And here is the code from match.c.<br />
<br />
bool<br />
hostname_matches(const char *shost, const char *lhost, const char *pattern)<br />
{<br />
    debug_decl(hostname_matches, SUDO_DEBUG_MATCH)<br />
    const char *host;<br />
    bool rc;<br />
<br />
    host = strchr(pattern, '.') != NULL ? lhost : shost;<br />
    if (has_meta(pattern)) {<br />
    rc = !fnmatch(pattern, host, FNM_CASEFOLD);<br />
    } else {<br />
    rc = !strcasecmp(host, pattern);<br />
    }<br />
    sudo_debug_printf(SUDO_DEBUG_DEBUG|SUDO_DEBUG_LINENO,<br />
    "host %s matches sudoers pattern %s: %s",<br />
    host, pattern, rc ? "true" : "false");<br />
    debug_return_bool(rc);<br />
}<br />
<br />
By the look of it it should match. I tried to find out how shost and lhost get their values - these are macros to a member of the sudo_user struct but that part is not debugged. Only thing I can confirm is that I do not get the<br />
<br />
log_warning(MSG_ONLY, N_("unable to resolve host %s"), user_host);<br />
<br />
from line 816 of sudoers.c.<br />
<br />
I also checked the hosts file and there I do have the<br />
<br />
192.168.110.3 nappali nappali.szilva<br />
<br />
entry.<br />
<br />
Still stuck whit this.<br />
 </div>