access idmap cache directly from smbd

[simo]

On Mon, 2008-08-18 at 16:28 -0700, Jeremy Allison wrote:
> On Mon, Aug 18, 2008 at 04:26:35PM -0700, Jeremy Allison wrote:
> > On Mon, Aug 18, 2008 at 06:18:59PM -0500, Gerald (Jerry) Carter wrote:
> > 
> > > I don't care as long as it's graceful failure over
> > > if the entry is not in the cache.  smbd should not
> > > be writing to the cache.
> > > 
> > > For example,
> > > 
> > > 	smbd_check_cache();
> > > 	if (!in_cache)
> > > 		ask_winbindd();
> > > 
> > > 	do_legacy_mapping()
> > > 
> > > 
> > > But in order to solve Volker's pdb_ldap.c issue, just make
> > > smbd in memory cache a tdb separate from winbind's cache
> > > and let smbd write all it wants.
> > 
> > Ok, I'm cool with that. We can even leave the current
> > in-memory cache code in place to do just that, and let
> > smbd look in the winbindd cache, followed by the local
> > in-memory cache before doing any lookup or legacy mapping.
> > 
> > Then if we have to fallback to the legacy mapping it just stores
> > in the old-style local memory cache as it used to.
> 
> Pseudocode to try and make things clearer...
> 
> smbd_check_winbindd_cache();
> if (!in_cache) {
> 	smbd_check_in_local_memory_cache();
> }
> if (!in_cache) {
> 	ask_winbindd();
> }
> 
> do_legacy_mapping_and_store_in_local_memory_cache();

I guess the main risk is in getting the wrong mappings in a long lived
shared cache (a wrong mapping in a temporary memory cache seem less
serious).

I think you can still store mappings from smbd if you really want to as
long as you do not store Unix Users/Groups mappings.

In sid_to[u|g]id() you can always resolve a Unix User/Group mapping
without needing to cache it as it can be the first check you do and it
is just a sid_peek_check_rid() (the hole point of Unix Users/Groups is
that you do not have to keep a mapping as the mapping is automatic after
all.

In [u|g]id_to_sid() the Unix Users/Groups mapping is a fallback and you
should not (imo) store it in the long term cache.

Mostly I am concerned with the wrong mapping getting into the cache,
it's bad enough (and potentially a security issue) if one smbd gets it
wrong, but if it also makes it wrong for all other smbds it is worse
(the tdb cache is shared between all process while the current in memory
cache is per process).

However, reducing the memory footprint by keeping a shared cache seem a
good thing. Also, the added benefit that one smbd populates the cache
for all others when a mapping is missing/expires instead of having each
smbd hitting winbindd is good.
So, I vote for a read-only access to the idmap cache. Read-Write worries
me a bit, but if there is some proof that will dramatically change
performances then I would accept the risk.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <simo at redhat.com>