On Fri, Jan 30, 2015 at 03:15:46PM +0100, Jakub Hrozek wrote:
On Fri, Jan 30, 2015 at 02:24:34PM +0100, Sumit Bose wrote:
> On Fri, Jan 30, 2015 at 02:23:43PM +0100, Sumit Bose wrote:
> > 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.
>
> and now with a patch.
ACK
Very late pushmail, sorry for the delay.
master: 561ed2fd03bab04cfdddbc09c4b48563c9d9b87e
sssd-1-12: 8b61b994f95f351d7036f4748e5c6f467698f6ae