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'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@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@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 '+'
    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@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,'.') != 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@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'm sorry for a late delay. Did you manage to create any progress on 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

Reply via email to