updated newidmap

[simo]

On Tue, 2006-10-03 at 20:12 +0200, Volker Lendecke wrote:
> On Tue, Oct 03, 2006 at 01:59:54PM -0400, simo wrote:
> > Uhmm mapping often requires allocation, I don't see what do you mean.
> 
> Right, but as we agreed not to do automatic allocation
> guarded by a magic flag, sid2uid would not allocate anymore.
> So it's two calls to the idmap api anyway.

No my idea was to make sid2uid always allocate if possible.
The IDmap will decide if the allocation can be performed by doing a
lookupsid to determine the sid is actually meningful.

> > > Proposal: Why don't we have two separate module interfaces,
> > > one for id mapping and another one for allocation. idmap_tdb
> > > and idmap_ldap would support the set_mapping call, whereas
> > > idmap_ad and others would not.
> > 
> > Can you elaborate some more?
> 
> A lot of the confusion in my head came from mixing up the
> two tasks allocation and mapping. If we go to have different
> backends per trusted domain, it is not entirely obvious
> which one the allocations would come from. This is why I
> would like to separate out that task.

The allocation is obvious as choosing the backend depends on the SID.
If the SID is from BUILTIN the backend for BUILTIN is asked, if the SID
is from DOMAIN_X the backend responsible for DOMAIN_X is used.
If the SID is from an unknown (in the sense that there isn't a specific
backend) the default backend is asked (usually this will be the tdb
backend).

> For example in the pure appliance scenario you might have
> only local allocation for the machine's SAM, whereas
> everything else comes from a centrally managed LDAP server.
> Or each of the boxes is able to ask the central LDAP server
> for new IDs, but for specific domains idmap_ad would kick
> in. All sorts of setups.

Sure, I am absolutely thinking in these terms, to me the scenario is
clear.

> A popular setup might be to have _only_ idmap_rid/idmap_ad.

This is taken in account in this case allocation will always fail.

> How would you do the allocation for the local stuff? pdb_tdb
> would take care of BUILTIN/LOCALSAM, but it would not be
> able to allocate IDs, because none of the backends can.

Correct.

>  And
> just for that purpose adding idmap_tdb would bring in too
> much functionality for my taste.

I agree, but the solution imo is that allocation will simply always fail
and BUILTIN users/groups will simply not be used.

How else could you do that?
There is no sane way I can see to allocate an id if you don't use
idmap_tdb with its own reserved range.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org