defining the new idmap subsystem

[simo]

Replying myself...

On Mon, 2006-10-02 at 23:35 -0400, simo wrote:
> The only real reason why we introduced the QUERY_ONLY flags is to avoid
> DOSs by depletion of usable ids. Ideally we always want to make an
> allocation if possible.

So actually this was the reason why I used it initially, but it seem
this has been changed later and now we actually allocate a SID only if
we can resolve it by a lookupsid call.
This is certainly a good anti-DOS measure, but I am not sure it covers
all the lawful cases. Need some more thinking. (hey this is exactly why
I am trying to publicly discuss this :-). But it is probably the best we
can do, so I will stick with this right now.

> So normally NOT allocating is a sort of side effect.

Indeed we do not allocate only when lookupsid doesn't return what we
want.

> > We must not add allocation as a side effect. Been there, done
> > that - had to track down the bugs. Not doing it again :-).
> 
> I am not sure what you propose will make it any better.
> We actually do make checks in winbindd we shouldn't and that's because
> we explicitly test before. I'd like to be as transparent as possible and
> let idmap decide what to do, I can't do it 100% of the time, that's why
> I need that flag, but I don't like to go and put back the logic in
> winbind, as it would be abused again and the policy will risk to not be
> consistent again.

Ok, so I have to reconsider this.
Let's try to put down what each piece of code needs and knows.

A) The code above IDmap just need to know if a mapping exists and
ideally always have an allocation if not. Unfortunately we cannot always
have a successful allocation, so the code above IDmap need to cope with
the fact the IDmap may say nay.

B) IDmap just needs to know what you are looking for and try to give you
back a mapping. Unfortunately IDmap has a constraint on the resources it
can use, so it must be conservative and map only if the mapping makes
sense.

This problem really exist only for sid -> unixid and not the other way
around as there is no way to make up a sid given just a unixid and we
already have the code to deal with the case thanks to Volker's UNIX
Domain SIDs (Would it make sense to put that code into IDmap? I think
so, but have not actually thought if that is desirable/possible. What do
you think Volker?).

We have determined that it make sense to create a mapping only if the
sid is really allocated (and of the right type) in the domain it belongs
to.

So far we have tried to resolve this problem by moving into winbind the
choice of whether or not to actually perform the mapping.
But we didn't think there is another way that will simplify the code and
let IDmap make the choice (as it belong there imo).

The idea is to make IDmap able to actually make an "upcall" to winbindd
to validate the SID by itself.

This will allow us to completely eliminate all the flags and duplicate
interfaces. And to really make the code allocation agnostic.

When IDmap will be presented a request for a mapping that does not exist
it will choose whether or not to ask winbindd for a lookupsid and then
decide what to do.

This will make it possible to:

1) optimize code paths
   - if we have a negative cache entry, we just leverage it
   - if we have finished the ID space we just return an error
   - if the backend cannot allocate ids or is readonly, it
     simply  doesn't make sense to check for the sid, we
     simply return an error an that's it
   - if the backend can allocate and is not readonly, then we
     make the check and eventually allocate

2) remove all the special cases
   - no code in samba will mess with allocation
   - all the decision are made where we have all the data to
     make a sensible decision and do it fast

what do you think?

Simo.



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