[SSSD] [sssd PR#128][comment] Fix group renaming issue when "id_provider = ldap" is set

2017-01-18 Thread fidencio 
  URL: https://github.com/SSSD/sssd/pull/128
Title: #128: Fix group renaming issue when "id_provider = ldap" is set

fidencio commented:
"""
CI: http://sssd-ci.duckdns.org/logs/job/60/61/summary.html

Debian testing failure is unrelated.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/128#issuecomment-273534076
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#128][comment] Fix group renaming issue when "id_provider = ldap" is set

2017-01-18 Thread fidencio 
  URL: https://github.com/SSSD/sssd/pull/128
Title: #128: Fix group renaming issue when "id_provider = ldap" is set

fidencio commented:
"""
CI: http://sssd-ci.duckdns.org/logs/job/60/61/summary.html

Debian testing failure is unrelated.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/128#issuecomment-273534076
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#128][opened] Fix group renaming issue when "id_provider = ldap" is set

2017-01-18 Thread fidencio 
   URL: https://github.com/SSSD/sssd/pull/128
Author: fidencio
 Title: #128: Fix group renaming issue when "id_provider = ldap" is set
Action: opened

PR body:
"""
Those two patches fix https://bugzilla.redhat.com/show_bug.cgi?id=1401241

The sssd.conf used in order to reproduce this issue looks like:

```
[sssd]
config_file_version = 2
services = nss, pam
domains = ad.fidencio.lan

[nss]

[pam]

[domain/ad.fidencio.lan]
ad_domain = ad.fidencio.lan
krb5_realm = AD.FIDENCIO.LAN
realmd_tags = manages-system joined-with-adcli 
cache_credentials = True
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
ldap_referrals = false
enumerate = false
id_provider = ldap
#id_provider = ad
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap
ldap_sasl_mech = GSSAPI
ldap_schema = ad
ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true

```

The reproducer can be found in the bug report.
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/128/head:pr128
git checkout pr128
From 4d7144de77b62f96567dc0e26e353bfe12fe6573 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= 
Date: Wed, 18 Jan 2017 16:39:22 +0100
Subject: [PATCH 1/2] SYSDB_OPS: Add a function to check if a group gid is
 unique
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The code has already been utilized sysdb_add_group() and now got split
into a new function in order to be re-utilized wherever is needed.

Related: rhbz#1401241

Signed-off-by: Fabiano Fidêncio 
---
 src/db/sysdb_ops.c | 53 ++---
 1 file changed, 38 insertions(+), 15 deletions(-)

diff --git a/src/db/sysdb_ops.c b/src/db/sysdb_ops.c
index cfa1586..b06ed4d 100644
--- a/src/db/sysdb_ops.c
+++ b/src/db/sysdb_ops.c
@@ -2041,6 +2041,41 @@ int sysdb_add_basic_group(struct sss_domain_info *domain,
 
 /* =Add-Group-Function */
 
+static int check_group_gid_is_unique(struct sss_domain_info *domain,
+ gid_t gid)
+{
+TALLOC_CTX *tmp_ctx;
+struct ldb_message *msg = NULL;
+int ret;
+
+tmp_ctx = talloc_new(NULL);
+if (!tmp_ctx) {
+return ENOMEM;
+}
+
+/* check no other groups with the same gid exist */
+if (gid != 0) {
+ret = sysdb_search_group_by_gid(tmp_ctx, domain, gid, NULL, );
+if (ret != ENOENT) {
+if (ret == EOK) {
+DEBUG(SSSDBG_TRACE_LIBS,
+  "Group with the same gid exists: [%"SPRIgid"].\n", gid);
+ret = EEXIST;
+} else {
+DEBUG(SSSDBG_TRACE_LIBS,
+  "sysdb_search_group_by_gid failed for gid: "
+  "[%"SPRIgid"].\n", gid);
+}
+goto done;
+}
+}
+
+ret = EOK;
+
+done:
+return ret;
+}
+
 int sysdb_add_group(struct sss_domain_info *domain,
 const char *name, gid_t gid,
 struct sysdb_attrs *attrs,
@@ -2093,21 +2128,9 @@ int sysdb_add_group(struct sss_domain_info *domain,
 }
 }
 
-/* check no other groups with the same gid exist */
-if (gid != 0) {
-ret = sysdb_search_group_by_gid(tmp_ctx, domain, gid, NULL, );
-if (ret != ENOENT) {
-if (ret == EOK) {
-DEBUG(SSSDBG_TRACE_LIBS,
-  "Group with the same gid exists: [%"SPRIgid"].\n", gid);
-ret = EEXIST;
-} else {
-DEBUG(SSSDBG_TRACE_LIBS,
-  "sysdb_search_group_by_gid failed for gid: "
-  "[%"SPRIgid"].\n", gid);
-}
-goto done;
-}
+ret = check_group_gid_is_unique(domain, gid);
+if (ret != EOK) {
+goto done;
 }
 
 /* try to add the group */

From 940caf729cdd81093c546e26eb72a40ff7fed708 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= 
Date: Wed, 18 Jan 2017 16:43:52 +0100
Subject: [PATCH 2/2] SYSDB_OPS: Avoid adding incomplete groups with duplicated
 GID
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This situation can be hit when renaming a group. Without this patch, the
renamed group would be added to the cache while the old entry would be
there as well, causing some issues like not showing the groupname when
calling `groups user`.

Now, we take the a similar approach taken by sysdb_add_groupp(), checking
whether the group gid already exists and then deleting the old entry
before adding the new one.

[SSSD] [sssd PR#85][comment] SYSDB: Removing of sysdb_try_to_find_expected_dn()

2017-01-18 Thread sumit-bose 
  URL: https://github.com/SSSD/sssd/pull/85
Title: #85: SYSDB: Removing of sysdb_try_to_find_expected_dn()

sumit-bose commented:
"""
I think sdap_object_in_domain() and sdap_domain_get_by_dn() are working as 
expected, only the debug message in the code-block you cited should be 
corrected to some thing like "The original DN of the group cannot be related to 
any search base".

sdap_object_in_domain() assumes by default that the given object belongs to the 
given group which can be seen in the handling of the missing DN. So it makes 
sense that if the DN cannot be matched to any search bases to assume the same, 
i.e. 'return true;'.

When test_user_is_from_another_domain() is run there is only one domain, 
"domain.test.com", available in opts->sdom when sdap_domain_get_by_dn() is 
called. The search base does not match to the DN of the object from 
"another_domain.test.com" and NULL is returned. If you setup the test so that 
there is at least "another_domain.test.com" in the opt->sdom list as well  
sdap_domain_get_by_dn() can return the domain and in sdap_object_in_domain() 
false can be returned because the domains are not the same.

HTH

bye,
Sumit
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/85#issuecomment-273496307
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: $ reconfig && chmake failed

2017-01-18 Thread Pavel Březina 

On 01/18/2017 10:44 AM, amit kumar wrote:

PASS: refcount-tests
FAIL: fail_over-tests
PASS: find_uid-tests
PASS: auth-tests
PASS: ipa_ldap_opt-tests
PASS: ad_ldap_opt-tests
PASS: crypto-tests
PASS: util-tests
PASS: debug-tests
PASS: ipa_hbac-tests
PASS: sss_idmap-tests
PASS: responder_socket_access-tests
PASS: sysdb-tests
PASS: safe-format-tests
PASS: sysdb_ssh-tests
PASS: sbus_tests
PASS: sbus_codegen_tests
PASS: test_fo_srv
PASS: resolv-tests

Testsuite summary for sssd 1.14.90

# TOTAL: 83
# PASS:  82
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./test-suite.log
Please report to sssd-devel@lists.fedorahosted.org


# vim ./test_suite.log


   sssd 1.14.90: ./test-suite.log


# TOTAL: 83
# PASS:  82
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: fail_over-tests
=

Running suite(s): fail_over
50%: Checks: 2, Failures: 1, Errors: 0
../src/tests/fail_over-tests.c:162:F:FAIL_OVER
Tests:test_fo_resolve_service:0: ../src/tests/fail_over-tests.c:254:
Expected return of 0, got 110
FAIL fail_over-tests (exit status: 1)



110 is ETIMEDOUT. Please re-run. This test is not reliable and fails 
sometimes due to timeout. It should be fixed.






--
Thanks
Amit Kumar
There are three ways to get something done:
  (1) Do it yourself.
  (2) Hire someone to do it for you.
  (3) Forbid your kids to do it.



___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org


___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: $ reconfig && chmake failed

2017-01-18 Thread Fabiano Fidêncio 
On Wed, Jan 18, 2017 at 10:44 AM, amit kumar  wrote:
> PASS: refcount-tests
> FAIL: fail_over-tests
> PASS: find_uid-tests
> PASS: auth-tests
> PASS: ipa_ldap_opt-tests
> PASS: ad_ldap_opt-tests
> PASS: crypto-tests
> PASS: util-tests
> PASS: debug-tests
> PASS: ipa_hbac-tests
> PASS: sss_idmap-tests
> PASS: responder_socket_access-tests
> PASS: sysdb-tests
> PASS: safe-format-tests
> PASS: sysdb_ssh-tests
> PASS: sbus_tests
> PASS: sbus_codegen_tests
> PASS: test_fo_srv
> PASS: resolv-tests
> 
> Testsuite summary for sssd 1.14.90
> 
> # TOTAL: 83
> # PASS:  82
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See ./test-suite.log
> Please report to sssd-devel@lists.fedorahosted.org
> 
>
> # vim ./test_suite.log
>
> 
>sssd 1.14.90: ./test-suite.log
> 
>
> # TOTAL: 83
> # PASS:  82
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
>
> .. contents:: :depth: 2
>
> FAIL: fail_over-tests
> =
>
> Running suite(s): fail_over
> 50%: Checks: 2, Failures: 1, Errors: 0
> ../src/tests/fail_over-tests.c:162:F:FAIL_OVER
> Tests:test_fo_resolve_service:0: ../src/tests/fail_over-tests.c:254:
> Expected return of 0, got 110
> FAIL fail_over-tests (exit status: 1)
>
>
>
>
> --
> Thanks
> Amit Kumar
> There are three ways to get something done:
>   (1) Do it yourself.
>   (2) Hire someone to do it for you.
>   (3) Forbid your kids to do it.
>
>
> ___
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
>

Which system are you using?

-- 
Fabiano Fidêncio
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] $ reconfig && chmake failed

2017-01-18 Thread amit kumar 
PASS: refcount-tests
FAIL: fail_over-tests
PASS: find_uid-tests
PASS: auth-tests
PASS: ipa_ldap_opt-tests
PASS: ad_ldap_opt-tests
PASS: crypto-tests
PASS: util-tests
PASS: debug-tests
PASS: ipa_hbac-tests
PASS: sss_idmap-tests
PASS: responder_socket_access-tests
PASS: sysdb-tests
PASS: safe-format-tests
PASS: sysdb_ssh-tests
PASS: sbus_tests
PASS: sbus_codegen_tests
PASS: test_fo_srv
PASS: resolv-tests

Testsuite summary for sssd 1.14.90

# TOTAL: 83
# PASS:  82
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./test-suite.log
Please report to sssd-devel@lists.fedorahosted.org


# vim ./test_suite.log


   sssd 1.14.90: ./test-suite.log


# TOTAL: 83
# PASS:  82
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: fail_over-tests
=

Running suite(s): fail_over
50%: Checks: 2, Failures: 1, Errors: 0
../src/tests/fail_over-tests.c:162:F:FAIL_OVER
Tests:test_fo_resolve_service:0: ../src/tests/fail_over-tests.c:254:
Expected return of 0, got 110
FAIL fail_over-tests (exit status: 1)




-- 
Thanks
Amit Kumar
There are three ways to get something done:
  (1) Do it yourself.
  (2) Hire someone to do it for you.
  (3) Forbid your kids to do it.

___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org