[SSSD] [PATCH] AD: use GC for SID requests as well

Sumit Bose sbose at redhat.com
Fri Jan 30 13:23:43 UTC 2015


On Fri, Jan 30, 2015 at 01:27:34PM +0100, Jakub Hrozek wrote:
> On Wed, Jan 28, 2015 at 08:18:04PM +0100, Sumit Bose wrote:
> > On Wed, Jan 28, 2015 at 04:21:53PM +0100, Sumit Bose wrote:
> > > On Wed, Jan 28, 2015 at 03:27:44PM +0100, Jakub Hrozek wrote:
> > > > On Wed, Jan 28, 2015 at 03:05:00PM +0100, Sumit Bose wrote:
> > > > > Hi,
> > > > > 
> > > > > another issue found by Steeve during testing. To reproduce this you need
> > > > > a universal group with members from different domains. Then either look
> > > > > up the group by SID e.g. with
> > > > > 
> > > > > python -c "import pysss_nss_idmap; print pysss_nss_idmap.getnamebysid('S-1-5-21-3456664713-2053453454-4165325232-1234')"
> > > > > 
> > > > > and then with getent group groupname.
> > > > > 
> > > > > Or use IPA views, override the group name in the 'default trust view'
> > > > > on the IPA server and look up the group by the overridden name. In both
> > > > > case the group should not already be in the cache. Only members from the
> > > > > domain of the group should be show without the patch.
> > > > > 
> > > > > bye,
> > > > > Sumit
> > > > 
> > > > The patch is correct, but I'm worried about the implications. What kind
> > > > of requests by SID does the server receive? Do we also resolve requests
> > > > for users by SID? In that case, we might be surprised that some POSIX
> > > > attributes are not available in GC..
> > > 
> > > good point, I'm working on a group only alternative.
> > 
> > Please find attached a slightly extended version. It tries to switch to
> > the LDAP connection in the common LDAP code. We already do similar
> > things during group requests in the common LDAP code so I hope this is
> > ok. This switch only happens during user_and_group request where it is
> > not clear if the match will be a user or a group, e.g. a search by SID.
> > I have to admit that there is a side effect because the AD provider uses
> > GC lookups with LDAP fallback for these types of requests and will be
> > affected by this change as well. But since the more detailed user
> > information will be available via LDAP this might even be a benefit.
> > 
> > bye,
> > Sumit
> 
> [...]
> 
> > -    if (state->sdap_ret == ENOENT) {
> > +    if (state->sdap_ret == ENOENT && state->noexist_delete == true) {
> 
> I don't think this change is correct, the noexist_delete check should be
> in its own nested if, otherwise looking up a SID that matches neither user
> nor group fails with EIO:

ah sorry, of course you are right new version attached.

bye,
Sumit

> Breakpoint 3, get_user_and_group_users_done (subreq=0x18beca0) at src/providers/ldap/ldap_id.c:1799
> 1799        struct tevent_req *req = tevent_req_callback_data(subreq,
> (gdb) n
> 1801        struct get_user_and_group_state *state = tevent_req_data(req,
> (gdb) 
> 1805        ret = users_get_recv(subreq, &state->dp_error, &state->sdap_ret);
> (gdb) 
> 1806        talloc_zfree(subreq);
> (gdb) 
> 1808        if (ret != EOK) {
> (gdb) 
> 1812        if (state->sdap_ret == ENOENT && state->noexist_delete == true) {
> (gdb) 
> 1822        } else if (state->sdap_ret != EOK) {
> (gdb) 
> 1823            tevent_req_error(req, EIO);
> (gdb) 
> 1824            return;
> (gdb) p state->sdap_ret
> $1 = 2
> (gdb) p state->noexist_delete 
> $2 = false
> (gdb) quit
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list