Hi,
if an entry is removed from LDAP and searched by SID, the SID lookup code doesn't handle ENOENT and doesn't remove the stray entry from cache. The attached patch fixes that.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/10/2013 02:13 PM, Jakub Hrozek wrote:
Hi,
if an entry is removed from LDAP and searched by SID, the SID lookup code doesn't handle ENOENT and doesn't remove the stray entry from cache. The attached patch fixes that.
One minor nitpick (no need to resend for review): the SSSBG_FATAL_FAILURE line is > 79 characters. Please reflow it.
Otherwise, code looks good to me. Ack.
On Thu, Oct 10, 2013 at 02:49:13PM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/10/2013 02:13 PM, Jakub Hrozek wrote:
Hi,
if an entry is removed from LDAP and searched by SID, the SID lookup code doesn't handle ENOENT and doesn't remove the stray entry from cache. The attached patch fixes that.
One minor nitpick (no need to resend for review): the SSSBG_FATAL_FAILURE line is > 79 characters. Please reflow it.
Otherwise, code looks good to me. Ack.
I agree, I just wonder if the new code can be move to a new call like e.g. sysdb_delete_by_sid() to make it easier to reuse it?
bye, Sumit
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJW9qkACgkQeiVVYja6o6Oc5wCfUV2IF3ZRlJRTj2xjqvAC08QV tdkAnRoFnbDJzxuNjEcTgEneZSJtFUrk =7ZOt -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Fri, Oct 11, 2013 at 09:37:54AM +0200, Sumit Bose wrote:
On Thu, Oct 10, 2013 at 02:49:13PM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/10/2013 02:13 PM, Jakub Hrozek wrote:
Hi,
if an entry is removed from LDAP and searched by SID, the SID lookup code doesn't handle ENOENT and doesn't remove the stray entry from cache. The attached patch fixes that.
One minor nitpick (no need to resend for review): the SSSBG_FATAL_FAILURE line is > 79 characters. Please reflow it.
Otherwise, code looks good to me. Ack.
I agree, I just wonder if the new code can be move to a new call like e.g. sysdb_delete_by_sid() to make it easier to reuse it?
bye, Sumit
Yes, I also noticed there is a duplication of search-by-sid functions in master. I will send updated patches, probably next week when I'm back. I don't think it's a pressing issue.
On Fri, Oct 11, 2013 at 09:59:17AM +0200, Jakub Hrozek wrote:
On Fri, Oct 11, 2013 at 09:37:54AM +0200, Sumit Bose wrote:
On Thu, Oct 10, 2013 at 02:49:13PM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/10/2013 02:13 PM, Jakub Hrozek wrote:
Hi,
if an entry is removed from LDAP and searched by SID, the SID lookup code doesn't handle ENOENT and doesn't remove the stray entry from cache. The attached patch fixes that.
One minor nitpick (no need to resend for review): the SSSBG_FATAL_FAILURE line is > 79 characters. Please reflow it.
Otherwise, code looks good to me. Ack.
I agree, I just wonder if the new code can be move to a new call like e.g. sysdb_delete_by_sid() to make it easier to reuse it?
bye, Sumit
Yes, I also noticed there is a duplication of search-by-sid functions in master. I will send updated patches, probably next week when I'm back. I don't think it's a pressing issue.
New patches attached. I haven't done anything about the duplication, I think it should better be solved when following up on Ondra's patches as the duplication (sysdb_search_object_by_sid vs sysdb_search_entry_by_sid) was introduced there.
On (22/10/13 14:59), Jakub Hrozek wrote:
On Fri, Oct 11, 2013 at 09:59:17AM +0200, Jakub Hrozek wrote:
On Fri, Oct 11, 2013 at 09:37:54AM +0200, Sumit Bose wrote:
On Thu, Oct 10, 2013 at 02:49:13PM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/10/2013 02:13 PM, Jakub Hrozek wrote:
Hi,
if an entry is removed from LDAP and searched by SID, the SID lookup code doesn't handle ENOENT and doesn't remove the stray entry from cache. The attached patch fixes that.
One minor nitpick (no need to resend for review): the SSSBG_FATAL_FAILURE line is > 79 characters. Please reflow it.
Otherwise, code looks good to me. Ack.
I agree, I just wonder if the new code can be move to a new call like e.g. sysdb_delete_by_sid() to make it easier to reuse it?
bye, Sumit
Yes, I also noticed there is a duplication of search-by-sid functions in master. I will send updated patches, probably next week when I'm back. I don't think it's a pressing issue.
New patches attached. I haven't done anything about the duplication, I think it should better be solved when following up on Ondra's patches as the duplication (sysdb_search_object_by_sid vs sysdb_search_entry_by_sid) was introduced there.
Works fine. ACK
LS
On Fri, Oct 25, 2013 at 04:19:02PM +0200, Lukas Slebodnik wrote:
On (22/10/13 14:59), Jakub Hrozek wrote:
On Fri, Oct 11, 2013 at 09:59:17AM +0200, Jakub Hrozek wrote:
On Fri, Oct 11, 2013 at 09:37:54AM +0200, Sumit Bose wrote:
On Thu, Oct 10, 2013 at 02:49:13PM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/10/2013 02:13 PM, Jakub Hrozek wrote:
Hi,
if an entry is removed from LDAP and searched by SID, the SID lookup code doesn't handle ENOENT and doesn't remove the stray entry from cache. The attached patch fixes that.
One minor nitpick (no need to resend for review): the SSSBG_FATAL_FAILURE line is > 79 characters. Please reflow it.
Otherwise, code looks good to me. Ack.
I agree, I just wonder if the new code can be move to a new call like e.g. sysdb_delete_by_sid() to make it easier to reuse it?
bye, Sumit
Yes, I also noticed there is a duplication of search-by-sid functions in master. I will send updated patches, probably next week when I'm back. I don't think it's a pressing issue.
New patches attached. I haven't done anything about the duplication, I think it should better be solved when following up on Ondra's patches as the duplication (sysdb_search_object_by_sid vs sysdb_search_entry_by_sid) was introduced there.
Works fine. ACK
LS
Pushed to master and sssd-1-11
On 10/10/2013 08:13 PM, Jakub Hrozek wrote:
Hi,
if an entry is removed from LDAP and searched by SID, the SID lookup code doesn't handle ENOENT and doesn't remove the stray entry from cache. The attached patch fixes that.
Hi, how does this cope with situation when the deleted object is a member of some groups?
On Fri, Oct 11, 2013 at 11:01:32AM +0200, Pavel Březina wrote:
On 10/10/2013 08:13 PM, Jakub Hrozek wrote:
Hi,
if an entry is removed from LDAP and searched by SID, the SID lookup code doesn't handle ENOENT and doesn't remove the stray entry from cache. The attached patch fixes that.
Hi, how does this cope with situation when the deleted object is a member of some groups?
The memberof plugin should kick in and remove the user from the groups.
I haven't tested this, because it's should be no different from removing a user who is a member of a group, but I will run a quick test before submitting the next patch.
On Tue, Oct 15, 2013 at 06:08:18PM +0200, Jakub Hrozek wrote:
On Fri, Oct 11, 2013 at 11:01:32AM +0200, Pavel Březina wrote:
On 10/10/2013 08:13 PM, Jakub Hrozek wrote:
Hi,
if an entry is removed from LDAP and searched by SID, the SID lookup code doesn't handle ENOENT and doesn't remove the stray entry from cache. The attached patch fixes that.
Hi, how does this cope with situation when the deleted object is a member of some groups?
The memberof plugin should kick in and remove the user from the groups.
I haven't tested this, because it's should be no different from removing a user who is a member of a group, but I will run a quick test before submitting the next patch.
Works fine btw.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Pavel Březina -
Stephen Gallagher -
Sumit Bose