[PATCH] passdb: Cache output from pdb_[ug]id_to_sid
Jeremy Allison
jra at samba.org
Mon Jan 5 17:12:08 MST 2015
On Tue, Jan 06, 2015 at 12:47:30PM +1300, Andrew Bartlett wrote:
> On Mon, 2015-01-05 at 20:53 +0100, Volker Lendecke wrote:
> > On Tue, Jan 06, 2015 at 08:13:55AM +1300, Andrew Bartlett wrote:
> > > On Mon, 2015-01-05 at 16:55 +0100, Volker Lendecke wrote:
> > > > Hi!
> > > >
> > > > Review&push appreciated!
> > > >
> > >
> > > Volker,
> > >
> > > This looks like exactly the kind of thing that got us into
> > > https://bugzilla.samba.org/show_bug.cgi?id=10720
> > >
> > > Please don't push until I get a chance to verify that it isn't possible
> > > to have an ID that is of type BOTH forced into being a UID here.
> >
> > Ok, I'll make this a customer only patch then.
> >
> > How do you recommend we solve this problem then? We really
> > need to cache the passdb lookups. We could go and implement
> > the cache at the ldap level, maybe the source4 ldap server
> > would be able to serve as a caching proxy?
>
> It is simpler than this: Just use the id.type that is returned from
> pdb_id_to_sid(), rather than overriding and forcing it as UID or GID.
>
> That is why we had to change the functions from
> pdb_uid_to_sid()/pdb_gid_to_sid() to pdb_id_to_sid() in 4.2, because
> otherwise the information on what type of ID to cache would not be
> available.
Hmmm. But looking inside pdb_id_to_sid() we see:
...
ret = pdb->id_to_sid(pdb, id, sid);
if (ret == true) {
idmap_cache_set_sid2unixid(sid, id);
}
...
So Volker's code should only be catching the
case where pdb_id_to_sid() returns false,
so will only be adding the cache entry
in the:
/* This is an unmapped user */
uid_to_unix_users_sid(uid, psid);
case inside legacy_uid_to_sid(). So in
this case we *know* the id.type is ID_TYPE_UID
(and is ID_TYPE_GID in the legacy_gid_to_sid()
case).
Volker - how about moving the additional
idmap_cache_set_sid2unixid() calls to the
"This is an unmapped user" or "This is an unmapped group"
cases ?
Does that fix the customer lookup problem ?
Cheers,
Jeremy.
More information about the samba-technical
mailing list