[Freeipa-users] Sudo entry not found by sssd in the cache db

Molnár Domokos kretebe at freemail.hu
Tue Sep 15 08:53:59 UTC 2015


 
Jakub Hrozek <jhrozek at redhat.com> írta:
>On Tue, Sep 15, 2015 at 09:13:09AM +0200, Molnár Domokos wrote:
>>  
>> Jakub Hrozek <jhrozek at redhat.com> írta:
>> >On Tue, Sep 15, 2015 at 07:25:17AM +0200, Molnár Domokos wrote:
>> >> 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.
>> >
>> >What is the output of 'hostname' ?
>> >
>> >I don't think sudo canonicalizes it..
>> >
>> >-- 
>>  doma at nappali:/home/doma> hostname
>> nappali
>
>Can you try setting it to nappali?
>
>#hostnamectl set-hostname nappali.silva
>on modern systems.
>
>> doma at nappali:/home/doma> hostname --fqdn
>> nappali.szilva 
 doma at nappali:/home/doma> su
Password:
nappali:/home/doma # hostnamectl set-hostname nappali.szilva
nappali:/home/doma # hostname
nappali.szilva
nappali:/home/doma # hostname --fqdn
nappali.szilvanappali:/home/doma # su doma
sh-4.2$ sudo ls
doma's password:
20140921.ZIP                                            Oracle_VM_VirtualBox_Extension_Pack-4.3.26-98988.vbox-extpack
42646515_eb8d7dcabe416247463f1bc8652adced.pdf  Now it works, the rule is matched.I'm not sure this is the intended way especially seeing the fqdn mechanism in the sudo code but I'll just keep it that way.Thank you. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150915/ffe6683d/attachment.htm>


More information about the Freeipa-users mailing list