Bug 13802 - idmap xid2sid cache churn
Summary: idmap xid2sid cache churn
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Winbind (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks: 13813
  Show dependency treegraph
 
Reported: 2019-02-22 11:47 UTC by Ralph Böhme
Modified: 2020-12-17 01:10 UTC (History)
3 users (show)

See Also:


Attachments
Patch for 4.8, 4.9 and 4.10 cherry-picked from master (12.61 KB, patch)
2019-02-25 08:40 UTC, Ralph Böhme
vl: review+
bjacke: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Böhme 2019-02-22 11:47:44 UTC
In setups with idmap_ad this may result in request flood to LDAP server.

In a member server setup using idmap_ad, under the following conditions we may end up sending all xid2sid request to the LDAP server sidestepping the cache due to cache churn:

- expired or non-existing cache entry for xid2sid mapping, it's likely required to be a frequently queried id like the gid of "Domain Users"

- steady stream of xid2sid requests for this id, eg 20 per second

The sequence of requests and processing:

START: xid2sid request 1 comes in

  XID2SID: check cache -> not existing (or
           expired)
  
  XID2SID: generates two internal xid2sid
           requests, the first for the internal
           domain, the second for the primary
           domain
  
  XID2SID_I: does not know about id, returns
             null sid, this gets stored in the
             cache

Now xid2sid request 2 comes in:

                                    XID2SID: check cache -> not existing (negative
                                             cache entry from request 1)
                                                    
                                    XID2SID: generates two internal xid2sid
                                             requests, the first for the internal
                                             domain, the second for the primary
                                             domain
    
  XID2SID_P: returns a SID for the id, this 
             gets stored in the cache

                                    XID2SID_I: does not know about id, returns
                                               null sid, this overwrite the result
                                              from request 1

Now xid2sid request 3 comes in, asf. As a result, the correct xid2SID cache entry keeps being overwritten and all requests are sent to the LDAP server.

Now the way to fix this: instead of updating the cache when the per-domain map request finished, update the cache after all domains had their say.
Comment 1 Ralph Böhme 2019-02-25 08:40:33 UTC
Created attachment 14868 [details]
Patch for 4.8, 4.9 and 4.10 cherry-picked from master
Comment 2 Ralph Böhme 2019-02-25 15:11:21 UTC
Reassigning to Karolin for inclusion in 4.8, 4.9 and 4.10.
Comment 3 Karolin Seeger 2019-03-04 10:33:19 UTC
(In reply to Ralph Böhme from comment #2:
Pushed to autobuild-v4-{10,9,8}-test.
Comment 4 Karolin Seeger 2019-03-06 08:56:44 UTC
(In reply to Karolin Seeger from comment #3)
Pushed to all branches.
Closing out bug report.

Thanks!