[Freeipa-users] Sudo entry not found by sssd in the cache db
Molnár Domokos
kretebe at freemail.hu
Thu Oct 1 09:20:20 UTC 2015
"Pavel Březina" <pbrezina at redhat.com> írta:
>On 09/15/2015 09:10 AM, Molnár Domokos wrote:
>>
>> "Molnár Domokos" <kretebe at 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" <kretebe at freemail.hu> írta:
>>>>
>>>>
>>>> "Pavel Březina" <pbrezina at 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 at nappali:/home/doma> sudo ls
>>>> > doma'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 'doma' matched without domain, user is doma
>>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>>> [sss_parse_name_for_domains]
>>>> > (0x0200): name 'doma' 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 at 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 'doma' matched without domain, user is doma
>>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>>> [sss_parse_name_for_domains]
>>>> > (0x0200): name 'doma' 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 at 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 at 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 at 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 '+'
>> 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 'nappali.szilva' ... 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, '.') != 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 at nappali:/home/doma> sudo ls
>> > doma'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 'doma' matched without domain, user is doma
>> > (Wed Sep
>> 9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>>
>> > (0x0200): name 'doma' 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 at 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
>> > (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 'doma' matched without domain, user is doma
>> > (Wed Sep
>> 9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>>
>> > (0x0200): name 'doma' 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 at 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
>> > (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 at 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 at 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 '+'
>> 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 'nappali.szilva' ... 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,'.') != 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, '.') != NULL ? lhost : shost;
>>
>> if the pattern contains a '.' 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, '.')) != 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 at nappali:/home/doma> cc test.c
>> doma at nappali:/home/doma> ./a.out
>> Canonname, user_host: nappali.szilva, nappali.szilva
>> Shost: nappali
>>
>> Seems OK.
>>
>> Any idea?
>
>Hi, I'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.
More information about the Freeipa-users
mailing list