[PATCH] sss_dp_get_domains_send(): set ret to EAGAIN if force is true

[Pavel Březina]

I found this bug when setting my own trust environment.

I was unable to match username@subdomain to subdomain. This patch puts 
me a step forward. I can match the subdomain now, but I can't get 
account info:

[sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_send] (0x0400): Executing 
extended operation
[sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_get_generic_ext_step] (0x0400): 
calling ldap_search_ext with 
[objectclass=ipaNTTrustedDomain][cn=trusts,dc=*].
[sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_done] (0x0400): 
ldap_extended_operation result: Operations error(1), (null)
[sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_get_user_done] (0x0040): s2n 
exop request failed.
[sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_id_op_done] (0x0200): communication 
error on cached connection, moving to next server
[sssd[nss]] [nss_cmd_getpwnam_dp_callback] (0x0040): Unable to get 
information from Data Provider

[Sumit Bose]

On Mon, Nov 05, 2012 at 05:54:10PM +0100, Pavel Březina wrote:
> I found this bug when setting my own trust environment.
>
> I was unable to match username@subdomain to subdomain. This patch
> puts me a step forward. I can match the subdomain now, but I can't
> get account info:
>
> [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_send] (0x0400):
> Executing extended operation
> [sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_get_generic_ext_step] (0x0400):
> calling ldap_search_ext with
> [objectclass=ipaNTTrustedDomain][cn=trusts,dc=*].
> [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_done] (0x0400):
> ldap_extended_operation result: Operations error(1), (null)
> [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_get_user_done] (0x0040): s2n
> exop request failed.
> [sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_id_op_done] (0x0200):
> communication error on cached connection, moving to next server
> [sssd[nss]] [nss_cmd_getpwnam_dp_callback] (0x0040): Unable to get
> information from Data Provider

I think the issue in sss_dp_get_domains_send() should be better fixed by

diff --git a/src/responder/common/responder_get_domains.c
b/src/responder/common/responder_get_domains.c
index f4bcbf1..468dd76 100644
--- a/src/responder/common/responder_get_domains.c
+++ b/src/responder/common/responder_get_domains.c
@@ -203,7 +203,8 @@ struct tevent_req
*sss_dp_get_domains_send(TALLOC_CTX *mem_ctx,

subreq = get_subdomains_send(req, rctx, state->dom,
                                  state->force, state->hint);
-    if (ret != EAGAIN) {
+    if (subreq == NULL) {
+        ret = ENOMEM;
         goto immediately;
     }
     tevent_req_set_callback(subreq, sss_dp_get_domains_process, req);

Can you check if this works for you as well?

About the exop error. This is typically an indication that winbind is
not working properly on the server. Please check your DNS configuration
and test if 'wbinfo -u' returns a list of Windows users.

bye,
Sumit
> From 72881c9dcfe7fd1c5e107af84c5be997eff5a78c Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Pavel=20B=C5=99ezina?= 
> Date: Mon, 5 Nov 2012 15:00:10 +0100
> Subject: [PATCH 1/2] sss_dp_get_domains_send(): set ret to EAGAIN if force is
>  true
>
> If force is true, ret may stay uninitialized and if ret == 0
> after the subrequest is send, we will go to immediate label.
> Data provider request is sent, but the answer is never processed.
> This prohibited subdomain from working correctly.
>
> src/responder/common/responder_get_domains.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/responder/common/responder_get_domains.c b/src/responder/common/responder_get_domains.c
> index f4bcbf14cb4aa8aff859e6429d417851267310c0..f9851b00b8d9e0aa4be5f63f993b96ded2b1e77d 100644
> --- a/src/responder/common/responder_get_domains.c
> +++ b/src/responder/common/responder_get_domains.c
> @@ -165,7 +165,9 @@ struct tevent_req *sss_dp_get_domains_send(TALLOC_CTX *mem_ctx,
>          goto immediately;
>      }
> if (!force) {
> if (force) {
>    ret = EAGAIN;
> } else {
>     ret = check_last_request(rctx, hint);
>     if (ret == EOK) {
>         DEBUG(SSSDBG_TRACE_FUNC,
>
> -- 
> 1.7.11.7
> sssd-devel mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Simo Sorce]

On Mon, 2012-11-05 at 18:16 +0100, Sumit Bose wrote:
> On Mon, Nov 05, 2012 at 05:54:10PM +0100, Pavel Březina wrote:
> > I found this bug when setting my own trust environment.
> >
> > I was unable to match username@subdomain to subdomain. This patch
> > puts me a step forward. I can match the subdomain now, but I can't
> > get account info:
> >
> > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_send] (0x0400):
> > Executing extended operation
> > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_get_generic_ext_step] (0x0400):
> > calling ldap_search_ext with
> > [objectclass=ipaNTTrustedDomain][cn=trusts,dc=*].
> > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_done] (0x0400):
> > ldap_extended_operation result: Operations error(1), (null)
> > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_get_user_done] (0x0040): s2n
> > exop request failed.
> > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_id_op_done] (0x0200):
> > communication error on cached connection, moving to next server
> > [sssd[nss]] [nss_cmd_getpwnam_dp_callback] (0x0040): Unable to get
> > information from Data Provider
>
> I think the issue in sss_dp_get_domains_send() should be better fixed by
>
> diff --git a/src/responder/common/responder_get_domains.c
> b/src/responder/common/responder_get_domains.c
> index f4bcbf1..468dd76 100644
> --- a/src/responder/common/responder_get_domains.c
> +++ b/src/responder/common/responder_get_domains.c
> @@ -203,7 +203,8 @@ struct tevent_req
> *sss_dp_get_domains_send(TALLOC_CTX *mem_ctx,
>  subreq = get_subdomains_send(req, rctx, state->dom,
>                               state->force, state->hint);
> if (ret != EAGAIN) {
> if (subreq == NULL) {
>    ret = ENOMEM;
>    goto immediately;
> }
>    tevent_req_set_callback(subreq, sss_dp_get_domains_process, req);
>
> Can you check if this works for you as well?
>
> About the exop error. This is typically an indication that winbind is
> not working properly on the server. Please check your DNS configuration
> and test if 'wbinfo -u' returns a list of Windows users.

In F17 I needed to put selinux in permissive mode at least for a while, 
not sure if the latest selinux policy works ok now, in F18 it should be
fine.

Simo.

[Pavel Březina]

On 11/05/2012 09:18 PM, Simo Sorce wrote:
> On Mon, 2012-11-05 at 18:16 +0100, Sumit Bose wrote:
> > On Mon, Nov 05, 2012 at 05:54:10PM +0100, Pavel Březina wrote:
> > > I found this bug when setting my own trust environment.
> > >
> > > I was unable to match username@subdomain to subdomain. This patch
> > > puts me a step forward. I can match the subdomain now, but I can't
> > > get account info:
> > >
> > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_send] (0x0400):
> > > Executing extended operation
> > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_get_generic_ext_step] (0x0400):
> > > calling ldap_search_ext with
> > > [objectclass=ipaNTTrustedDomain][cn=trusts,dc=*].
> > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_done] (0x0400):
> > > ldap_extended_operation result: Operations error(1), (null)
> > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_get_user_done] (0x0040): s2n
> > > exop request failed.
> > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_id_op_done] (0x0200):
> > > communication error on cached connection, moving to next server
> > > [sssd[nss]] [nss_cmd_getpwnam_dp_callback] (0x0040): Unable to get
> > > information from Data Provider
> >
> > I think the issue in sss_dp_get_domains_send() should be better fixed by
> >
> > diff --git a/src/responder/common/responder_get_domains.c
> > b/src/responder/common/responder_get_domains.c
> > index f4bcbf1..468dd76 100644
> > --- a/src/responder/common/responder_get_domains.c
> > +++ b/src/responder/common/responder_get_domains.c
> > @@ -203,7 +203,8 @@ struct tevent_req
> > *sss_dp_get_domains_send(TALLOC_CTX *mem_ctx,
> >   subreq = get_subdomains_send(req, rctx, state->dom,
> >                                state->force, state->hint);
> > if (ret != EAGAIN) {
> > if (subreq == NULL) {
> >    ret = ENOMEM;
> >     goto immediately;
> > }
> > tevent_req_set_callback(subreq, sss_dp_get_domains_process, req);
> >
> > Can you check if this works for you as well?
> >
> > About the exop error. This is typically an indication that winbind is
> > not working properly on the server. Please check your DNS configuration
> > and test if 'wbinfo -u' returns a list of Windows users.
>
> In F17 I needed to put selinux in permissive mode at least for a while,
> not sure if the latest selinux policy works ok now, in F18 it should be
> fine.

Disabling selinux didn't help.

# wbinfo --online-status
BUILTIN : online
IPAMASTERVM : online
SSSD-AD : online

# wbinfo -n "SSSD-AD\sudo_test"
S-1-5-21-320631442-856505621-960413496-5141 SID_USER (1)

# wbinfo -s "S-1-5-21-320631442-856505621-960413496-5141"
SSSD-AD\sudo_test 1

# wbinfo -u
list of users

[Pavel Březina]

On 11/05/2012 06:16 PM, Sumit Bose wrote:
> On Mon, Nov 05, 2012 at 05:54:10PM +0100, Pavel Březina wrote:
> > I found this bug when setting my own trust environment.
> >
> > I was unable to match username@subdomain to subdomain. This patch
> > puts me a step forward. I can match the subdomain now, but I can't
> > get account info:
> >
> > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_send] (0x0400):
> > Executing extended operation
> > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_get_generic_ext_step] (0x0400):
> > calling ldap_search_ext with
> > [objectclass=ipaNTTrustedDomain][cn=trusts,dc=*].
> > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_done] (0x0400):
> > ldap_extended_operation result: Operations error(1), (null)
> > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_get_user_done] (0x0040): s2n
> > exop request failed.
> > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_id_op_done] (0x0200):
> > communication error on cached connection, moving to next server
> > [sssd[nss]] [nss_cmd_getpwnam_dp_callback] (0x0040): Unable to get
> > information from Data Provider
>
> I think the issue in sss_dp_get_domains_send() should be better fixed by
>
> diff --git a/src/responder/common/responder_get_domains.c
> b/src/responder/common/responder_get_domains.c
> index f4bcbf1..468dd76 100644
> --- a/src/responder/common/responder_get_domains.c
> +++ b/src/responder/common/responder_get_domains.c
> @@ -203,7 +203,8 @@ struct tevent_req
> *sss_dp_get_domains_send(TALLOC_CTX *mem_ctx,
>   subreq = get_subdomains_send(req, rctx, state->dom,
>                                state->force, state->hint);
> if (ret != EAGAIN) {
> if (subreq == NULL) {
>    ret = ENOMEM;
>     goto immediately;
> }
> tevent_req_set_callback(subreq, sss_dp_get_domains_process, req);
>
> Can you check if this works for you as well?
>
> About the exop error. This is typically an indication that winbind is
> not working properly on the server. Please check your DNS configuration
> and test if 'wbinfo -u' returns a list of Windows users.
>
> bye,
> Sumit

Yes, this is better.
I'm sending the patch.

[Sumit Bose]

On Tue, Nov 06, 2012 at 03:36:37PM +0100, Pavel Březina wrote:
> On 11/05/2012 06:16 PM, Sumit Bose wrote:
> > On Mon, Nov 05, 2012 at 05:54:10PM +0100, Pavel Březina wrote:
> > > I found this bug when setting my own trust environment.
> > >
> > > I was unable to match username@subdomain to subdomain. This patch
> > > puts me a step forward. I can match the subdomain now, but I can't
> > > get account info:
> > >
> > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_send] (0x0400):
> > > Executing extended operation
> > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_get_generic_ext_step] (0x0400):
> > > calling ldap_search_ext with
> > > [objectclass=ipaNTTrustedDomain][cn=trusts,dc=*].
> > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_done] (0x0400):
> > > ldap_extended_operation result: Operations error(1), (null)
> > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_get_user_done] (0x0040): s2n
> > > exop request failed.
> > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_id_op_done] (0x0200):
> > > communication error on cached connection, moving to next server
> > > [sssd[nss]] [nss_cmd_getpwnam_dp_callback] (0x0040): Unable to get
> > > information from Data Provider
> >
> > I think the issue in sss_dp_get_domains_send() should be better fixed by
> >
> > diff --git a/src/responder/common/responder_get_domains.c
> > b/src/responder/common/responder_get_domains.c
> > index f4bcbf1..468dd76 100644
> > --- a/src/responder/common/responder_get_domains.c
> > +++ b/src/responder/common/responder_get_domains.c
> > @@ -203,7 +203,8 @@ struct tevent_req
> > *sss_dp_get_domains_send(TALLOC_CTX *mem_ctx,
> >  subreq = get_subdomains_send(req, rctx, state->dom,
> >                               state->force, state->hint);
> > if (ret != EAGAIN) {
> > if (subreq == NULL) {
> >    ret = ENOMEM;
> >    goto immediately;
> > }
> >    tevent_req_set_callback(subreq, sss_dp_get_domains_process, req);
> >
> > Can you check if this works for you as well?
> >
> > About the exop error. This is typically an indication that winbind is
> > not working properly on the server. Please check your DNS configuration
> > and test if 'wbinfo -u' returns a list of Windows users.
> >
> > bye,
> > Sumit
>
> Yes, this is better.
> I'm sending the patch.

ACK

bye,
Sumit

[Jakub Hrozek]

On Tue, Nov 06, 2012 at 03:50:59PM +0100, Sumit Bose wrote:
> On Tue, Nov 06, 2012 at 03:36:37PM +0100, Pavel Březina wrote:
> > On 11/05/2012 06:16 PM, Sumit Bose wrote:
> > > On Mon, Nov 05, 2012 at 05:54:10PM +0100, Pavel Březina wrote:
> > > > I found this bug when setting my own trust environment.
> > > >
> > > > I was unable to match username@subdomain to subdomain. This patch
> > > > puts me a step forward. I can match the subdomain now, but I can't
> > > > get account info:
> > > >
> > > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_send] (0x0400):
> > > > Executing extended operation
> > > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_get_generic_ext_step] (0x0400):
> > > > calling ldap_search_ext with
> > > > [objectclass=ipaNTTrustedDomain][cn=trusts,dc=*].
> > > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_exop_done] (0x0400):
> > > > ldap_extended_operation result: Operations error(1), (null)
> > > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [ipa_s2n_get_user_done] (0x0040): s2n
> > > > exop request failed.
> > > > [sssd[be[IPA-SUDO-SUBDOMAIN]]] [sdap_id_op_done] (0x0200):
> > > > communication error on cached connection, moving to next server
> > > > [sssd[nss]] [nss_cmd_getpwnam_dp_callback] (0x0040): Unable to get
> > > > information from Data Provider
> > >
> > > I think the issue in sss_dp_get_domains_send() should be better fixed by
> > >
> > > diff --git a/src/responder/common/responder_get_domains.c
> > > b/src/responder/common/responder_get_domains.c
> > > index f4bcbf1..468dd76 100644
> > > --- a/src/responder/common/responder_get_domains.c
> > > +++ b/src/responder/common/responder_get_domains.c
> > > @@ -203,7 +203,8 @@ struct tevent_req
> > > *sss_dp_get_domains_send(TALLOC_CTX *mem_ctx,
> > >  subreq = get_subdomains_send(req, rctx, state->dom,
> > >                               state->force, state->hint);
> > > if (ret != EAGAIN) {
> > > if (subreq == NULL) {
> > >    ret = ENOMEM;
> > >    goto immediately;
> > > }
> > >    tevent_req_set_callback(subreq, sss_dp_get_domains_process, req);
> > >
> > > Can you check if this works for you as well?
> > >
> > > About the exop error. This is typically an indication that winbind is
> > > not working properly on the server. Please check your DNS configuration
> > > and test if 'wbinfo -u' returns a list of Windows users.
> > >
> > > bye,
> > > Sumit
> >
> > Yes, this is better.
> > I'm sending the patch.
>
> ACK
>
> bye,
> Sumit

Pushed to master and sssd-1-9