summaryrefslogtreecommitdiffstats
path: root/source3/lib/id_cache.c
Commit message (Collapse)AuthorAgeFilesLines
* s3:id_cache: do not use the in-memory idmap cache (it is going to be removed)Michael Adam2012-04-201-90/+0
| | | | This also removes the ID_CACHE_FLUSH message.
* s3:smbcontrol: let smbd pass the idmap msg to its children for convenienceGregor Beck2011-10-121-12/+12
| | | | Signed-off-by: Michael Adam <obnox@samba.org>
* s3: fix id_cache_kill to delete the the id-mappig from cachesGregor Beck2011-10-121-2/+2
| | | | | | | | The intendet and documented behavior of smbcontrol smbd idmap kill is to delete the mapping from caches and additionally kill the smbd if an affected id is in use. Signed-off-by: Michael Adam <obnox@samba.org>
* s3-passdb: Keep caches coherentAndreas Schneider2011-08-211-0/+15
| | | | | | | | | | | When deleting a user send a message to all interested parties so they can purge their caches. Otherwise some processes may positively respond with a cached getpwnam, when the user have actully been removed. Without this some tests that remove and then immediately create users are flakey. Signed-off-by: Simo Sorce <idra@samba.org>
* s3-id_cache: Use better names for id cache management opsAndreas Schneider2011-08-211-13/+13
| | | | | | | The IDMAP term is normally associated with Winbind's idmap stuff. These functions deal with id caching not id mapping. Signed-off-by: Simo Sorce <idra@samba.org>
* s3-id_cache: Move id caches mgmt out of smbdAndreas Schneider2011-08-211-0/+190
We must leave the MSG_IDMAP_KILL operation in SMBD as it uses smbd specific internal globals and makes sense only in the context of a smbd daemon. The rest is moved under lib/ as we need to deal with id cache cleanups in other daemons too (like lsasd). Signed-off-by: Simo Sorce <idra@samba.org>