Jakub Hrozek <jhro...@redhat.com> írta:
>On Tue, Sep 15, 2015 at 09:13:09AM +0200, Molnár Domokos wrote:
>>  
>> Jakub Hrozek <jhro...@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" <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.
>> >
>> >What is the output of &#39;hostname&#39; ?
>> >
>> >I don&#39;t think sudo canonicalizes it..
>> >
>> >-- 
>>  doma@nappali:/home/doma> hostname
>> nappali
>
>Can you try setting it to nappali?
>
>#hostnamectl set-hostname nappali.silva
>on modern systems.
>
>> doma@nappali:/home/doma> hostname --fqdn
>> nappali.szilva 
 doma@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&#39;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&#39;m not sure this is the intended way especially seeing the fqdn 
mechanism in the sudo code but I&#39;ll just keep it that way.Thank you. 
-- 
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