"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?
-- 
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