Discussion:
Sudo entry not found by sssd in the cache db
(too old to reply)
Molnár Domokos
2015-09-09 19:31:36 UTC
Permalink
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. ***@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 [***@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 [***@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?
Pavel Březina
2015-09-11 10:32:43 UTC
Permalink
Post by Molnár Domokos
I have a working IPA server and a working client config on an OpenSuse
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 is not allowed to run sudo on nappali. This incident will be reported.
Received client version [1].
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_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_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.
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
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!
--
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 pr
Molnár Domokos
2015-09-11 12:26:24 UTC
Permalink
Post by Pavel Březina
Post by Molnár Domokos
I have a working IPA server and a working client config on an OpenSuse
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 is not allowed to run sudo on nappali. This incident will be reported.
Received client version [1].
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_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_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.
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
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 :) (Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [***@szilva]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [***@szilva]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving default options for [doma] from [szilva]
(Fri Sep 11 14:19:57 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<=1441973997)))]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [<default options>@szilva]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using protocol version [1]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name &#39;doma&#39; matched without domain, user is doma
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name &#39;doma&#39; matched without domain, user is doma
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [doma] from [<ALL>]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [***@szilva]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [***@szilva]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [doma] from [szilva]
(Fri Sep 11 14:19:57 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<=1441973997)))]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache
(Fri Sep 11 14:19:57 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=+*)))]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [***@szilva]
(Fri Sep 11 14:20:00 2015) [sssd[sudo]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
(Fri Sep 11 14:20:00 2015) [sssd[sudo]] [client_recv] (0x0200): Client disconnected!
(Fri Sep 11 14:20:00 2015) [sssd[sudo]] [client_destructor] (0x2000): Terminated client [0x8f6abd0][17]
(Fri Sep 11 14:20:10 2015) [sssd[sudo]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit as doma: ***@nappali:/home/doma> id
uid=1816400003(doma) gid=1816400003(doma) groups=1816400003(doma),16(dialout),33(video),112(vboxusers),1000(burning),1816400006(picture_access)
***@nappali:/home/doma> hostname --fqdn
nappali.szilva
***@nappali:/home/doma> domainname
szilva
***@nappali:/home/doma> nisdomainname
szilva
***@nappali:/home/doma> dnsdomainname
szilva
***@nappali:/home/doma> sudo ls
doma&#39;s password:
doma is not allowed to run sudo on nappali. This incident will be reported.
***@nappali:/home/doma> as root: nappali:~ # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*helios.szilva 193.6.222.47 3 u 56 64 377 0.779 1.365 0.420
LOCAL(0) .LOCL. 10 l 535 64 0 0.000 0.000 0.000
nappali:~ # helios.szilva is the standalone IPA server.
Molnár Domokos
2015-09-11 12:40:37 UTC
Permalink
Post by Molnár Domokos
Post by Pavel Březina
Post by Molnár Domokos
I have a working IPA server and a working client config on an OpenSuse
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 is not allowed to run sudo on nappali. This incident will be reported.
Received client version [1].
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_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_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.
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
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!
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving default options for [doma] from [szilva]
(Fri Sep 11 14:19:57 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<=1441973997)))]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using protocol version [1]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name &#39;doma&#39; matched without domain, user is doma
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name &#39;doma&#39; matched without domain, user is doma
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [doma] from [<ALL>]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [doma] from [szilva]
(Fri Sep 11 14:19:57 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<=1441973997)))]
(Fri Sep 11 14:19:57 2015) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache
(Fri Sep 11 14:19:57 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=+*)))]
(Fri Sep 11 14:20:00 2015) [sssd[sudo]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
(Fri Sep 11 14:20:00 2015) [sssd[sudo]] [client_recv] (0x0200): Client disconnected!
(Fri Sep 11 14:20:00 2015) [sssd[sudo]] [client_destructor] (0x2000): Terminated client [0x8f6abd0][17]
uid=1816400003(doma) gid=1816400003(doma) groups=1816400003(doma),16(dialout),33(video),112(vboxusers),1000(burning),1816400006(picture_access)
nappali.szilva
szilva
szilva
szilva
doma is not allowed to run sudo on nappali. This incident will be reported.
remote refid st t when poll reach delay offset jitter
==============================================================================
*helios.szilva 193.6.222.47 3 u 56 64 377 0.779 1.365 0.420
LOCAL(0) .LOCL. 10 l 535 64 0 0.000 0.000 0.000
nappali:~ # helios.szilva is the standalone IPA server.
Pavel Březina
2015-09-14 13:08:11 UTC
Permalink
Full log attached.
Post by Molnár Domokos
I have a working IPA server and a working client config on an OpenSuse
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 is not allowed to run sudo on nappali. This incident will be reported.
Received client version [1].
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_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_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.
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
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 ***@trace

Run sudo and send us /var/log/sudo_debug? Thanks!
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go t
Molnár Domokos
2015-09-15 05:25:17 UTC
Permalink
Full log attached.
Post by Molnár Domokos
I have a working IPA server and a working client config on an OpenSuse
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 is not allowed to run sudo on nappali. This incident will be reported.
Received client version [1].
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_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_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.
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
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?
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 ***@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.
Jakub Hrozek
2015-09-15 06:39:22 UTC
Permalink
Post by Molnár Domokos
Full log attached.
Post by Molnár Domokos
I have a working IPA server and a working client config on an OpenSuse
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 is not allowed to run sudo on nappali. This incident will be reported.
Received client version [1].
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_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_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.
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
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?
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.
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] in_res=0xb7c9c1b8, count=1, act=INCLUDE
Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading &#39;+&#39;
Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost &#39;nappali.szilva&#39; ... not
Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1 -> 0)
Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) => f_sss_result=(0xb7c9e410, 0)
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 'hostname' ?

I don't think sudo canonicalizes it..
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://free
Molnár Domokos
2015-09-15 07:10:39 UTC
Permalink
Post by Molnár Domokos
Full log attached.
Post by Molnár Domokos
I have a working IPA server and a working client config on an OpenSuse
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 is not allowed to run sudo on nappali. This incident will be reported.
Received client version [1].
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_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_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.
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
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?
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.
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] in_res=0xb7c9c1b8, count=1, act=INCLUDE
Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading &#39;+&#39;
Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost &#39;nappali.szilva&#39; ... not
Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1 -> 0)
Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) => f_sss_result=(0xb7c9e410, 0)
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.
Full log attached.
I have a working IPA server and a working client config on an OpenSuse
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 is not allowed to run sudo on nappali. This incident will be reported.
Received client version [1].
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_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_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.
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
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?
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.
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] in_res=0xb7c9c1b8, count=1, act=INCLUDE
Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
Sep 14 22:13:39 sudo[2314]
Sep 14 22:13:39 sudo[2314]
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]
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.
--
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:

***@nappali:/home/doma> cc test.c
***@nappali:/home/doma> ./a.out
Canonname, user_host: nappali.szilva, nappali.szilva
Shost: nappali

Seems OK.

Any idea?
Pavel Březina
2015-09-29 11:49:25 UTC
Permalink
Post by Molnár Domokos
Post by Pavel Březina
Full log attached.
Post by Molnár Domokos
I have a working IPA server and a working client
config on an OpenSuse
Post by Molnár Domokos
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
Post by Molnár Domokos
user "doma". However when the user tries to use sudo
the rule does not
Post by Molnár Domokos
work.
doma is not allowed to run sudo on nappali. This
incident will be reported.
Post by Molnár Domokos
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
Received client version [1].
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
Offered version [1].
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
[sss_parse_name_for_domains]
Post by Molnár Domokos
(0x0200): name 'doma' matched without domain, user is doma
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
[sss_parse_name_for_domains]
Post by Molnár Domokos
(0x0200): name 'doma' matched without domain, user is doma
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
[sudosrv_cmd_parse_query_done]
Post by Molnár Domokos
(0x0200): Requesting default options for [doma] from
[<ALL>]
Post by Molnár Domokos
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
Post by Molnár Domokos
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
Searching sysdb with
Post by Molnár Domokos
[(&(objectClass=sudoRule)(|(name=defaults)))]
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
[sss_parse_name_for_domains]
Post by Molnár Domokos
(0x0200): name 'doma' matched without domain, user is doma
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
[sss_parse_name_for_domains]
Post by Molnár Domokos
(0x0200): name 'doma' matched without domain, user is doma
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
[sudosrv_cmd_parse_query_done]
Post by Molnár Domokos
(0x0200): Requesting rules for [doma] from [<ALL>]
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
Post by Molnár Domokos
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
Post by Molnár Domokos
(Wed Sep 9 21:25:30 2015) [sssd[sudo]] [client_recv]
(0x0200): Client
Post by Molnár Domokos
disconnected!
This seems perfectly OK with one exception. The query
against the sysdb
Post by Molnár Domokos
does not find the entry. This is strange because the
entry is there.
Post by Molnár Domokos
(Wed Sep 2 08:52:13 2015) [sssd]
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
Post by Molnár Domokos
Running the exact same query seen above in the
sssd_sudo.log against the
Post by Molnár Domokos
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=+*)))"
Post by Molnár Domokos
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
name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
Post by Molnár Domokos
# returned 1 records
# 1 entries
# 0 referrals
This confirms that the entry is indeed there in the
db. Why is it found
Post by Molnár Domokos
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?
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
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] in_res=0xb7c9c1b8, count=1, act=INCLUDE
Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
Sep 14 22:13:39 sudo[2314] IP address nappali.szilva matches local
Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading '+'
Sep 14 22:13:39 sudo[2314] host nappali matches sudoers pattern
Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost 'nappali.szilva' ... not
Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1 -> 0)
Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) =>
f_sss_result=(0xb7c9e410, 0)
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.
Full log attached.
Post by Pavel Březina
I have a working IPA server and a working client config on an OpenSuse
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
Post by Pavel Březina
work.
doma is not allowed to run sudo on nappali.
This incident will be reported.
Post by Pavel Březina
(Wed Sep
Received client version [1].
(Wed Sep
Offered version [1].
(Wed Sep
9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
Post by Pavel Březina
(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]
Post by Pavel Březina
(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]
Post by Pavel Březina
(0x0200): Requesting default options for [doma] from []
(Wed Sep
(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]
Post by Pavel Březina
(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]
Post by Pavel Březina
(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]
Post by Pavel Březina
(0x0200): Requesting rules for [doma] from []
(Wed Sep
(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
Post by Pavel Březina
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.
(Wed Sep
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
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=+*)))"
Post by Pavel Březina
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?
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.
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] in_res=0xb7c9c1b8, count=1, act=INCLUDE
Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
Sep 14 22:13:39 sudo[2314]
Sep 14 22:13:39 sudo[2314]
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]
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.
--
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
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);
}
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 t
Molnár Domokos
2015-09-15 07:13:09 UTC
Permalink
Post by Molnár Domokos
Full log attached.
Post by Molnár Domokos
I have a working IPA server and a working client config on an OpenSuse
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 is not allowed to run sudo on nappali. This incident will be reported.
Received client version [1].
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_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_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.
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
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?
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.
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] in_res=0xb7c9c1b8, count=1, act=INCLUDE
Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading &#39;+&#39;
Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost &#39;nappali.szilva&#39; ... not
Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1 -> 0)
Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) => f_sss_result=(0xb7c9e410, 0)
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..
--
***@nappali:/home/doma> hostname
nappali
***@nappali:/home/doma> hostname --fqdn
nappali.szilva
Jakub Hrozek
2015-09-15 08:07:42 UTC
Permalink
Post by Molnár Domokos
Post by Molnár Domokos
Full log attached.
Post by Molnár Domokos
I have a working IPA server and a working client config on an OpenSuse
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 is not allowed to run sudo on nappali. This incident will be reported.
Received client version [1].
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_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_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.
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
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?
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.
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] in_res=0xb7c9c1b8, count=1, act=INCLUDE
Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading &#39;+&#39;
Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost &#39;nappali.szilva&#39; ... not
Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1 -> 0)
Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) => f_sss_result=(0xb7c9e410, 0)
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..
--
nappali
Can you try setting it to nappali?

#hostnamectl set-hostname nappali.silva
on modern systems.
Post by Molnár Domokos
nappali.szilva
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for mo
Molnár Domokos
2015-09-15 08:53:59 UTC
Permalink
Post by Jakub Hrozek
Post by Molnár Domokos
Post by Molnár Domokos
Full log attached.
Post by Molnár Domokos
I have a working IPA server and a working client config on an OpenSuse
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 is not allowed to run sudo on nappali. This incident will be reported.
Received client version [1].
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_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_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.
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
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?
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.
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] in_res=0xb7c9c1b8, count=1, act=INCLUDE
Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading &#39;+&#39;
Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost &#39;nappali.szilva&#39; ... not
Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1 -> 0)
Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) => f_sss_result=(0xb7c9e410, 0)
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..
--
nappali
Can you try setting it to nappali?
#hostnamectl set-hostname nappali.silva
on modern systems.
Post by Molnár Domokos
nappali.szilva
***@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.
Alexander Bokovoy
2015-09-15 10:58:07 UTC
Permalink
Post by Molnár Domokos
Post by Jakub Hrozek
#hostnamectl set-hostname nappali.silva
on modern systems.
Post by Molnár Domokos
nappali.szilva
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
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.
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.
--
/ Alexander Bokovoy
--
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
Jakub Hrozek
2015-09-15 11:37:48 UTC
Permalink
Post by Alexander Bokovoy
Post by Molnár Domokos
Post by Jakub Hrozek
#hostnamectl set-hostname nappali.silva
on modern systems.
Post by Molnár Domokos
nappali.szilva
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
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.
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.
You can have registered a different hostname with IPA than what
hostname(1) reports, we have an ipa_hostname parameter for that. But
there's no way for sudo to learn about it..
Post by Alexander Bokovoy
--
/ Alexander Bokovoy
--
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
Molnár Domokos
2015-09-15 13:59:52 UTC
Permalink
#hostnamectl set-hostname nappali.silva on modern systems.
sudo doesn&#39;t do normalization and IPA&#39;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.
You can have registered a different hostname with IPA than what hostname(1) reports, we have an ipa_hostname parameter for that. But there&#39;s no way for sudo to learn about it..
You may well be right but I still think this is a bug in sudo/sssd plugin. Here&#39;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 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 &#39;.&#39; 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.
Molnár Domokos
2015-10-01 09:20:20 UTC
Permalink
Post by Molnár Domokos
Post by Pavel Březina
Full log attached.
Post by Molnár Domokos
I have a working IPA server and a working client
config on an OpenSuse
Post by Molnár Domokos
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
Post by Molnár Domokos
user "doma". However when the user tries to use sudo
the rule does not
Post by Molnár Domokos
work.
doma is not allowed to run sudo on nappali. This
incident will be reported.
Post by Molnár Domokos
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
Received client version [1].
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
Offered version [1].
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
[sss_parse_name_for_domains]
Post by Molnár Domokos
(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]
Post by Molnár Domokos
(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]
Post by Molnár Domokos
(0x0200): Requesting default options for [doma] from
[<ALL>]
Post by Molnár Domokos
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
Post by Molnár Domokos
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
Searching sysdb with
Post by Molnár Domokos
[(&(objectClass=sudoRule)(|(name=defaults)))]
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
[sss_parse_name_for_domains]
Post by Molnár Domokos
(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]
Post by Molnár Domokos
(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]
Post by Molnár Domokos
(0x0200): Requesting rules for [doma] from [<ALL>]
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
Post by Molnár Domokos
(Wed Sep 9 21:25:25 2015) [sssd[sudo]]
Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
Post by Molnár Domokos
(Wed Sep 9 21:25:30 2015) [sssd[sudo]] [client_recv]
(0x0200): Client
Post by Molnár Domokos
disconnected!
This seems perfectly OK with one exception. The query
against the sysdb
Post by Molnár Domokos
does not find the entry. This is strange because the
entry is there.
Post by Molnár Domokos
(Wed Sep 2 08:52:13 2015) [sssd]
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
Post by Molnár Domokos
Running the exact same query seen above in the
sssd_sudo.log against the
Post by Molnár Domokos
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=+*)))"
Post by Molnár Domokos
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
name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
Post by Molnár Domokos
# returned 1 records
# 1 entries
# 0 referrals
This confirms that the entry is indeed there in the
db. Why is it found
Post by Molnár Domokos
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?
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
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] in_res=0xb7c9c1b8, count=1, act=INCLUDE
Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
false
Sep 14 22:13:39 sudo[2314] IP address nappali.szilva matches local
Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading &#39;+&#39;
Sep 14 22:13:39 sudo[2314] host nappali matches sudoers pattern
Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost &#39;nappali.szilva&#39; ... not
false
:= 0
Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1
-> 0)
:= 0xb7c9e410
Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) =>
f_sss_result=(0xb7c9e410, 0)
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.
Full log attached.
Post by Pavel Březina
I have a working IPA server and a working client config on an OpenSuse
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
Post by Pavel Březina
work.
doma is not allowed to run sudo on nappali.
This incident will be reported.
Post by Pavel Březina
(Wed Sep
Received client version [1].
(Wed Sep
Offered version [1].
(Wed Sep
9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
Post by Pavel Březina
(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]
Post by Pavel Březina
(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]
Post by Pavel Březina
(0x0200): Requesting default options for [doma] from []
(Wed Sep
(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]
Post by Pavel Březina
(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]
Post by Pavel Březina
(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]
Post by Pavel Březina
(0x0200): Requesting rules for [doma] from []
(Wed Sep
(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
Post by Pavel Březina
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.
(Wed Sep
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
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=+*)))"
Post by Pavel Březina
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?
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.
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] in_res=0xb7c9c1b8, count=1, act=INCLUDE
Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
Sep 14 22:13:39 sudo[2314]
Sep 14 22:13:39 sudo[2314]
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]
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.
--
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
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);
}
Canonname, user_host: nappali.szilva, nappali.szilva
Shost: nappali
Seems OK.
Any idea?
Hi, I&#39;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.
Post by Molnár Domokos
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.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more inf
Continue reading on narkive:
Loading...