On Fri, 2012-05-04 at 14:30 +0200, Jan Zelený wrote: > Done. We have to proceed with the approach now, as the basic concept > of ghost > members shifted a little bit in coparison with the original patch set. > Ghost > attribute now co-exists with the memberuid, they don't overlap on any > level > whatsoever. > One comment here. With either the previous or current code I am having some difficulty determining if the ghost attributes (ane memberuid with the previous approach) of groups are appropriately handled if ghost groups should change after a new group lookup.
Assume a user is never actually resolved, but is deleted or renamed in the LDAP server. Are we properly handling updating the relative ghost group all around ? It would be nice to see a unit test to check this behavior. The issue is connected to the way you implemented removing the ghost attribute for the user name (and its aliases) in patch 120. I have the impression that if by the time the real user is looked up it has changed (say it has one more alias) that the operation may fail as not ghost entry with the 'new' alias is found so the delete operation may fail due to the value not being in there. The delete operation in that case may need to be split into a looks/match/delete operation as a fallback (doing it by default would probably kill a bit performances so perhaps a fallback case is better). Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
