"Pavel Březina" <pbrez...@redhat.com> írta:
>On 09/15/2015 09:10 AM, Molnár Domokos wrote:
>>
>> "Molnár Domokos" <kret...@freemail.hu> írta:
>>
>>     On 09/14/2015 03:08 PM, Pavel Březina wrote:
>>>     On 09/11/2015 02:40 PM, Molnár Domokos wrote:
>>>>     Full log attached.
>>>>     "Molnár Domokos" <kret...@freemail.hu> írta:
>>>>
>>>>
>>>>         "Pavel Březina" <pbrez...@redhat.com> írta:
>>>>
>>>>             On 09/09/2015 09:31 PM, Molnár Domokos wrote:
>>>>              > I have a working IPA server and a working client
>>>>     config on an OpenSuse
>>>>              > 13.2 with the following versions:
>>>>              > nappali:~ # rpm -qa |grep sssd
>>>>              > sssd-tools-1.12.2-3.4.1.i586
>>>>              > sssd-krb5-1.12.2-3.4.1.i586
>>>>              > python-sssd-config-1.12.2-3.4.1.i586
>>>>              > sssd-ipa-1.12.2-3.4.1.i586
>>>>              > sssd-1.12.2-3.4.1.i586
>>>>              > sssd-dbus-1.12.2-3.4.1.i586
>>>>              > sssd-krb5-common-1.12.2-3.4.1.i586
>>>>              > sssd-ldap-1.12.2-3.4.1.i586
>>>>              > sssd is confihured for nss, pam, sudo
>>>>              > There is a test sudo rule defined in the ipa server,
>>>>     which applies to
>>>>              > user "doma".  However when the user tries to use sudo
>>>>     the rule does not
>>>>              > work.
>>>>              > doma@nappali:/home/doma> sudo ls
>>>>              > doma&#39;s password:
>>>>              > doma is not allowed to run sudo on nappali.  This
>>>>     incident will be reported.
>>>>              > The corresponding log in the sssd_sudo.log is this:
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>     [sss_cmd_get_version] (0x0200):
>>>>              > Received client version [1].
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>     [sss_cmd_get_version] (0x0200):
>>>>              > Offered version [1].
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>     [sss_parse_name_for_domains]
>>>>              > (0x0200): name &#39;doma&#39; matched without domain, user 
>>>> is doma
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>     [sss_parse_name_for_domains]
>>>>              > (0x0200): name &#39;doma&#39; matched without domain, user 
>>>> is doma
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>     [sudosrv_cmd_parse_query_done]
>>>>              > (0x0200): Requesting default options for [doma] from
>>>>     [<ALL>]
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>     [sudosrv_get_user] (0x0200):
>>>>              > Requesting info about [doma@szilva]
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>              > [sudosrv_get_sudorules_query_cache] (0x0200):
>>>>     Searching sysdb with
>>>>              >
>>>>     
>>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>              > [sudosrv_get_sudorules_query_cache] (0x0200):
>>>>     Searching sysdb with
>>>>              > [(&(objectClass=sudoRule)(|(name=defaults)))]
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>     [sss_parse_name_for_domains]
>>>>              > (0x0200): name &#39;doma&#39; matched without domain, user 
>>>> is doma
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>     [sss_parse_name_for_domains]
>>>>              > (0x0200): name &#39;doma&#39; matched without domain, user 
>>>> is doma
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>     [sudosrv_cmd_parse_query_done]
>>>>              > (0x0200): Requesting rules for [doma] from [<ALL>]
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>     [sudosrv_get_user] (0x0200):
>>>>              > Requesting info about [doma@szilva]
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>              > [sudosrv_get_sudorules_query_cache] (0x0200):
>>>>     Searching sysdb with
>>>>              >
>>>>     
>>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
>>>>              > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>>>              > [sudosrv_get_sudorules_query_cache] (0x0200):
>>>>     Searching sysdb with
>>>>              >
>>>>     
>>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
>>>>              > (Wed Sep  9 21:25:30 2015) [sssd[sudo]] [client_recv]
>>>>     (0x0200): Client
>>>>              > disconnected!
>>>>              > This seems perfectly OK with one exception. The query
>>>>     against the sysdb
>>>>              > does not find the entry. This is strange because the
>>>>     entry is there.
>>>>              > Log in sssd.log:
>>>>              > (Wed Sep  2 08:52:13 2015) [sssd]
>>>>     [sysdb_domain_init_internal] (0x0200):
>>>>              > DB File for szilva: /var/lib/sss/db/cache_szilva.ldb
>>>>              > So we know that the sysdb is
>>>>     /var/lib/sss/db/cache_szilva.ldb
>>>>              > Running the exact same query seen above in the
>>>>     sssd_sudo.log against the
>>>>              > db returns:
>>>>              > ldbsearch -H /var/lib/sss/db/cache_szilva.ldb
>>>>              >
>>>>     
>>>> "(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))"
>>>>              > asq: Unable to register control with rootdse!
>>>>              > # record 1
>>>>              > dn: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
>>>>              > cn: Doma_ls
>>>>              > dataExpireTimestamp: 1441830262
>>>>              > entryUSN: 20521
>>>>              > name: Doma_ls
>>>>              > objectClass: sudoRule
>>>>              > originalDN: cn=Doma_ls,ou=sudoers,dc=szilva
>>>>              > sudoCommand: ls
>>>>              > sudoHost: nappali.szilva
>>>>              > sudoRunAsGroup: ALL
>>>>              > sudoRunAsUser: ALL
>>>>              > sudoUser: doma
>>>>              > distinguishedName:
>>>>     name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
>>>>              > # returned 1 records
>>>>              > # 1 entries
>>>>              > # 0 referrals
>>>>              > This confirms that the entry is indeed there in the
>>>>     db. Why is it found
>>>>              > with ldbsearch and why does sssd_sudo not find it?
>>>>              > I am pretty much stuck with this one. Anyone has an idea?
>>>>              >
>>>>              >
>>>>             Hi,
>>>>             this is strange. Can you provide the logs with debug
>>>>     level set to 0x3ff0
>>>>
>>>>             please? Can you also send it as an attachment? Thanks!
>>>>
>>>>         Sure. Here it is. Now I can see that the rule is returned. The
>>>>         question is why the rule does not match. Anyway much better :)
>>>
>>>     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?
>>>
>>>     Debug sudo /var/log/sudo_debug all@trace
>>>
>>>     Run sudo and send us /var/log/sudo_debug? Thanks
>>
>>     Thanks for the tip with the proper debug syntax - I was unable to
>>     get a single log item out of sudo before.
>>
>>     I think I have found something. This is the relevant part of the
>>     output of all@debug (you need this not trace I think):
>>
>>     Sep 14 22:13:39 sudo[2314]   username=doma
>>     Sep 14 22:13:39 sudo[2314] domainname=NULL
>>     Sep 14 22:13:39 sudo[2314] state |= USERMATCH
>>     Sep 14 22:13:39 sudo[2314] Received 1 rule(s)
>>     Sep 14 22:13:39 sudo[2314] -> sudo_sss_filter_result @ ./sssd.c:175
>>     Sep 14 22:13:39 sudo[2314] in_res=0xb7c9c1b8, count=1, act=INCLUDE
>>     Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
>>     Sep 14 22:13:39 sudo[2314] -> sudo_sss_result_filterp @ ./sssd.c:648
>>     Sep 14 22:13:39 sudo[2314] -> sudo_sss_check_host @ ./sssd.c:556
>>     Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
>>     Sep 14 22:13:39 sudo[2314] -> addr_matches @ ./match_addr.c:206
>>     Sep 14 22:13:39 sudo[2314] -> addr_matches_if @ ./match_addr.c:61
>>     Sep 14 22:13:39 sudo[2314] <- addr_matches_if @ ./match_addr.c:71 :=
>>     false
>>     Sep 14 22:13:39 sudo[2314] IP address nappali.szilva matches local
>>     host: false @ addr_matches() ./match_addr.c:217
>>     Sep 14 22:13:39 sudo[2314] <- addr_matches @ ./match_addr.c:218 := false
>>     Sep 14 22:13:39 sudo[2314] -> netgr_matches @ ./match.c:941
>>     Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading 
>> &#39;+&#39;
>>     Sep 14 22:13:39 sudo[2314] <- netgr_matches @ ./match.c:953 := false
>>     Sep 14 22:13:39 sudo[2314] -> hostname_matches @ ./match.c:776
>>     Sep 14 22:13:39 sudo[2314] host nappali matches sudoers pattern
>>     nappali.szilva: false @ hostname_matches() ./match.c:788
>>     Sep 14 22:13:39 sudo[2314] <- hostname_matches @ ./match.c:789 := false
>>     Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost &#39;nappali.szilva&#39; 
>> ... not
>>     Sep 14 22:13:39 sudo[2314] <- sudo_sss_check_host @ ./sssd.c:591 :=
>>     false
>>     Sep 14 22:13:39 sudo[2314] <- sudo_sss_result_filterp @ ./sssd.c:654
>>     := 0
>>     Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1
>>     -> 0)
>>     Sep 14 22:13:39 sudo[2314] <- sudo_sss_filter_result @ ./sssd.c:221
>>     := 0xb7c9e410
>>     Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) =>
>>     f_sss_result=(0xb7c9e410, 0)
>>     Sep 14 22:13:39 sudo[2314] <- sudo_sss_result_get @ ./sssd.c:728 :=
>>     0xb7c9e410
>>     Sep 14 22:13:39 sudo[2314] searching SSSD/LDAP for sudoers entries
>>     Sep 14 22:13:39 sudo[2314] Done with LDAP searches
>>
>>
>>     And here is the code from match.c.
>>
>>     bool
>>     hostname_matches(const char *shost, const char *lhost, const char
>>     *pattern)
>>     {
>>          debug_decl(hostname_matches, SUDO_DEBUG_MATCH)
>>          const char *host;
>>          bool rc;
>>
>>          host = strchr(pattern, &#39;.&#39;) != NULL ? lhost : shost;
>>          if (has_meta(pattern)) {
>>          rc = !fnmatch(pattern, host, FNM_CASEFOLD);
>>          } else {
>>          rc = !strcasecmp(host, pattern);
>>          }
>>          sudo_debug_printf(SUDO_DEBUG_DEBUG|SUDO_DEBUG_LINENO,
>>          "host %s matches sudoers pattern %s: %s",
>>          host, pattern, rc ? "true" : "false");
>>          debug_return_bool(rc);
>>     }
>>
>>     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
>>
>>     log_warning(MSG_ONLY, N_("unable to resolve host %s"), user_host);
>>
>>     from line 816 of sudoers.c.
>>
>>     I also checked the hosts file and there I do have the
>>
>>     192.168.110.3 nappali nappali.szilva
>>
>>     entry.
>>
>>     Still stuck whit this.
>>     On 09/14/2015 03:08 PM, Pavel Březina wrote:
>>     On 09/11/2015 02:40 PM, Molnár Domokos wrote:
>>     Full log attached.
>>     "Molnár Domokos"  írta:
>>
>>
>>          "Pavel Březina"  írta:
>>
>>              On 09/09/2015 09:31 PM, Molnár Domokos wrote:
>>
>>      > I have a working IPA server and a working client config on an OpenSuse
>>               > 13.2 with the following versions:
>>               > nappali:~ # rpm -qa |grep sssd
>>               > sssd-tools-1.12.2-3.4.1.i586
>>               > sssd-krb5-1.12.2-3.4.1.i586
>>               > python-sssd-config-1.12.2-3.4.1.i586
>>               > sssd-ipa-1.12.2-3.4.1.i586
>>               > sssd-1.12.2-3.4.1.i586
>>               > sssd-dbus-1.12.2-3.4.1.i586
>>               > sssd-krb5-common-1.12.2-3.4.1.i586
>>               > sssd-ldap-1.12.2-3.4.1.i586
>>               > sssd is confihured for nss, pam, sudo
>>
>>      > There is a test sudo rule defined in the ipa server, which applies to
>>               > user "doma".
>>     However when the user tries to use sudo the rule does not
>>               > work.
>>               > doma@nappali:/home/doma> sudo ls
>>               > doma&#39;s password:
>>               > doma is not allowed to run sudo on nappali.
>>     This incident will be reported.
>>               > The corresponding log in the sssd_sudo.log is this:
>>               > (Wed Sep
>>     9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
>>               > Received client version [1].
>>               > (Wed Sep
>>     9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
>>               > Offered version [1].
>>               > (Wed Sep
>>     9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>>
>>      > (0x0200): name &#39;doma&#39; matched without domain, user is doma
>>               > (Wed Sep
>>     9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>>
>>      > (0x0200): name &#39;doma&#39; matched without domain, user is doma
>>               > (Wed Sep
>>     9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
>>               > (0x0200): Requesting default options for [doma] from []
>>               > (Wed Sep
>>     9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
>>               > Requesting info about [doma@szilva]
>>               > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>
>>      > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>>
>>      > 
>> [(&amp;(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&amp;(dataExpireTimestamp
>>               > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>
>>      > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>>               > [(&amp;(objectClass=sudoRule)(|(name=defaults)))]
>>               > (Wed Sep
>>     9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>>
>>      > (0x0200): name &#39;doma&#39; matched without domain, user is doma
>>               > (Wed Sep
>>     9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>>
>>      > (0x0200): name &#39;doma&#39; matched without domain, user is doma
>>               > (Wed Sep
>>     9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
>>               > (0x0200): Requesting rules for [doma] from []
>>               > (Wed Sep
>>     9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
>>               > Requesting info about [doma@szilva]
>>               > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>
>>      > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>>
>>      > 
>> [(&amp;(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&amp;(dataExpireTimestamp
>>               > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
>>
>>      > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>>
>>      > 
>> [(&amp;(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
>>               > (Wed Sep
>>     9 21:25:30 2015) [sssd[sudo]] [client_recv] (0x0200): Client
>>               > disconnected!
>>
>>      > This seems perfectly OK with one exception. The query against the 
>> sysdb
>>
>>      > does not find the entry. This is strange because the entry is there.
>>               > Log in sssd.log:
>>               > (Wed Sep
>>     2 08:52:13 2015) [sssd] [sysdb_domain_init_internal] (0x0200):
>>               > DB File for szilva: /var/lib/sss/db/cache_szilva.ldb
>>
>>      > So we know that the sysdb is /var/lib/sss/db/cache_szilva.ldb
>>
>>      > Running the exact same query seen above in the sssd_sudo.log against 
>> the
>>               > db returns:
>>               > ldbsearch -H /var/lib/sss/db/cache_szilva.ldb
>>               >
>>     
>> "(&amp;(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))"
>>               > asq: Unable to register control with rootdse!
>>               > # record 1
>>               > dn: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
>>               > cn: Doma_ls
>>               > dataExpireTimestamp: 1441830262
>>               > entryUSN: 20521
>>               > name: Doma_ls
>>               > objectClass: sudoRule
>>               > originalDN: cn=Doma_ls,ou=sudoers,dc=szilva
>>               > sudoCommand: ls
>>               > sudoHost: nappali.szilva
>>               > sudoRunAsGroup: ALL
>>               > sudoRunAsUser: ALL
>>               > sudoUser: doma
>>
>>      > distinguishedName: 
>> name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
>>               > # returned 1 records
>>               > # 1 entries
>>               > # 0 referrals
>>
>>      > This confirms that the entry is indeed there in the db. Why is it 
>> found
>>               > with ldbsearch and why does sssd_sudo not find it?
>>               > I am pretty much stuck with this one. Anyone has an idea?
>>               >
>>               >
>>              Hi,
>>
>>     this is strange. Can you provide the logs with debug level set to 0x3ff0
>>
>>              please? Can you also send it as an attachment? Thanks!
>>
>>          Sure. Here it is. Now I can see that the rule is returned. The
>>          question is why the rule does not match. Anyway much better :)
>>
>>     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?
>>
>>     Debug sudo /var/log/sudo_debug all@trace
>>
>>     Run sudo and send us /var/log/sudo_debug? Thanks
>>
>>     Thanks for the tip with the proper debug syntax - I was unable to get a 
>> single log item out of sudo before.
>>
>>     I think I have found something. This is the relevant part of the output 
>> of all@debug (you need this not trace I think):
>>
>>     Sep 14 22:13:39 sudo[2314]   username=doma
>>     Sep 14 22:13:39 sudo[2314] domainname=NULL
>>     Sep 14 22:13:39 sudo[2314] state |= USERMATCH
>>     Sep 14 22:13:39 sudo[2314] Received 1 rule(s)
>>     Sep 14 22:13:39 sudo[2314] -> sudo_sss_filter_result @ ./sssd.c:175
>>     Sep 14 22:13:39 sudo[2314] in_res=0xb7c9c1b8, count=1, act=INCLUDE
>>     Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
>>     Sep 14 22:13:39 sudo[2314] -> sudo_sss_result_filterp @ ./sssd.c:648
>>     Sep 14 22:13:39 sudo[2314] -> sudo_sss_check_host @ ./sssd.c:556
>>     Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
>>     Sep 14 22:13:39 sudo[2314] -> addr_matches @ ./match_addr.c:206
>>     Sep 14 22:13:39 sudo[2314] -> addr_matches_if @ ./match_addr.c:61
>>     Sep 14 22:13:39 sudo[2314]
>>     Sep 14 22:13:39 sudo[2314] IP address nappali.szilva matches local host: 
>> false @ addr_matches() ./match_addr.c:217
>>     Sep 14 22:13:39 sudo[2314]
>>     Sep 14 22:13:39 sudo[2314] -> netgr_matches @ ./match.c:941
>>     Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading 
>> &#39;+&#39;
>>     Sep 14 22:13:39 sudo[2314]
>>     Sep 14 22:13:39 sudo[2314] -> hostname_matches @ ./match.c:776
>>     Sep 14 22:13:39 sudo[2314] host nappali matches sudoers pattern 
>> nappali.szilva: false @ hostname_matches() ./match.c:788
>>     Sep 14 22:13:39 sudo[2314]
>>     Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost &#39;nappali.szilva&#39; 
>> ... not
>>     Sep 14 22:13:39 sudo[2314]
>>     Sep 14 22:13:39 sudo[2314]
>>     Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1 -> 
>> 0)
>>     Sep 14 22:13:39 sudo[2314]
>>     Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) => 
>> f_sss_result=(0xb7c9e410, 0)
>>     Sep 14 22:13:39 sudo[2314]
>>     Sep 14 22:13:39 sudo[2314] searching SSSD/LDAP for sudoers entries
>>     Sep 14 22:13:39 sudo[2314] Done with LDAP searches
>>
>>
>>     And here is the code from match.c.
>>
>>     bool
>>     hostname_matches(const char *shost, const char *lhost, const char 
>> *pattern)
>>     {
>>          debug_decl(hostname_matches, SUDO_DEBUG_MATCH)
>>          const char *host;
>>          bool rc;
>>
>>          host = strchr(pattern,&#39;.&#39;) != NULL ? lhost : shost;
>>          if (has_meta(pattern)) {
>>          rc = !fnmatch(pattern, host, FNM_CASEFOLD);
>>          } else {
>>          rc = !strcasecmp(host, pattern);
>>          }
>>         sudo_debug_printf(SUDO_DEBUG_DEBUG|SUDO_DEBUG_LINENO,
>>         "host %s matches sudoers pattern %s: %s",
>>          host, pattern, rc ? "true" : "false");
>>          debug_return_bool(rc);
>>     }
>>
>>     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
>>
>>     log_warning(MSG_ONLY, N_("unable to resolve host %s"), user_host);
>>
>>     from line 816 of sudoers.c.
>>
>>     I also checked the hosts file and there I do have the
>>
>>     192.168.110.3 nappali nappali.szilva
>>
>>     entry.
>>
>>     Still stuck whit this.
>>
>>     --
>>     Manage your subscription for the Freeipa-users mailing list:
>>     https://www.redhat.com/mailman/listinfo/freeipa-users
>>     Go to http://freeipa.org for more info on the project
>>
>> Additional info. In match.c
>>
>> 780     host = strchr(pattern, &#39;.&#39;) != NULL ? lhost : shost;
>>
>> if the pattern contains a &#39;.&#39; then lhost is used, which is then
>>
>> 784         rc = !strcasecmp(host, pattern);
>>
>> compared with the pattern. In our case - from the debug log - host is
>> "nappali" while the pattern is "nappali.szilva".
>>
>> Clearly from some reason lhost does not contain the fqdn as it should. I
>> also tested the set_fqdn at line 806 in sudoers.c with this code:
>>
>> void
>> main(void)
>> {
>>      struct addrinfo *res0, hint;
>>      char *p;
>>      char *user_host, *user_shost;
>>
>>      user_host=malloc(500);
>>      user_shost=malloc(500);
>>
>>      memset(&hint, 0, sizeof(hint));
>>      hint.ai_family = PF_UNSPEC;
>>      hint.ai_flags = AI_FQDN;
>>      if (getaddrinfo("nappali", NULL, &hint, &res0) != 0) {
>>          printf("unable to resolve host %s", user_host);
>>      } else {
>>          user_host = strdup(res0->ai_canonname);
>>          printf ("Canonname, user_host: %s,
>> %s\n",res0->ai_canonname,user_host);
>>          if ((p = strchr(user_host, &#39;.&#39;)) != NULL)
>>              user_shost = strndup(user_host, (size_t)(p - user_host));
>>          else
>>              user_shost = user_host;
>>      }
>> printf("Shost: %s\n",user_shost);
>> }
>>
>> This outputs on the host in question:
>>
>> doma@nappali:/home/doma> cc test.c
>> doma@nappali:/home/doma> ./a.out
>> Canonname, user_host: nappali.szilva, nappali.szilva
>> Shost: nappali
>>
>> Seems OK.
>>
>> Any idea?
>
>Hi, I&#39;m sorry for a late delay. Did you manage to create any progress on 
>this?
> 

Hi, yes. Actually a workaround had been identified. One needs to set hostname 
to the fqdn and then it works. 

On Tue, Sep 15, 2015 at 01:58:07PM +0300, Alexander Bokovoy wrote:
>> sudo doesn't do normalization and IPA's way of exposing host names is by 
>> using by default fqdn. So sudo compares local hostname with fqdn-based one, 
>> guess which way it will succeed? You theoretically could have every hostname 
>> in IPA registered non-fqdn but what you cannot have is a mix between fqdn- 
>> and non-fqdn names.

And I replied:
You may well be right but I still think this is a bug in sudo/sssd plugin. As 
sudo does indeed try to nomalize, but it fails. Here's why I think so:

@line  582 in sssd.c: when calling hostname_matches it is a clear intention of 
the code that the hostname matching is done both against the fqdn and the naked 
hostname.

@lines 773-790 in match.c: the implementation of hostname_matches(..) is done 
correctly. It guesses intelligently and chooses to match either against the 
fqdn or the naked hostname based on the format of the hostname provided by IPA. 
If there is a '.' in the IPA provided hostname name then the hostname compared 
to the fqdn otherwise it is compared to the bare hostname.

@line 805 in sudoers.c in set_fqdn the fqdn is correctly retrieved for the host 
during initialization - so sudo is indeed aware of both host name versions. I 
tested this part it it works OK.

The bug - I think - is that the information correctly retrieved during init 
through set_fqdn in sudoers.c somehow does not make its way to line 582 in 
sssd.c. There both user_shost and user_host seem to contain the naked hostname 
unless the bare hostaname contains the fqdn itself.

I do not have enough time to find out why this happens but the above evidence 
suggests that there is a bug somewhere in the process.
 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to