Commit my stuff to 3.0?

[Andrew Bartlett]

Simo Sorce wrote:
> 
> On Sun, 2002-10-13 at 14:58, Andrew Bartlett wrote:
> > Simo Sorce wrote:
> > > Isn't idmap the right place to go?
> >
> > I think so.  And I think we can construct one that makes sense for
> > admins.  For example, we could contstruct an LDAP based one that uses
> > the uidNumber on the user's LDAP record.
> 
> I would only ask you to take in account we must have a generalized way
> to do it that does not rely on ldap, but can use different methods.

Yep.  I just know the LDAP requirements fairly well, but they are just
an example.

> > We might end up doing this via the passdb interface (despite the fact I
> > was really hoping to move unix stuff out of there) becouse I found the
> > performance issues surrounding the current stuff to be problematic.  :-(
> 
> can you explain, this phrasing is criptic to me.

We have performance issues with the current way we do this.  One way to
solve this is to push all of this back into the pdb module, as it can
perform optomisations.

> > Whatever we do, uid->sid and sid->uid needs to be a single lookup.
> 
> you mean we have to be sure we do a single query to idmap? or something
> else?

As you mention below, these call happen a lot - the idmap should
implement this in as efficient way as possible.

> > idra:  you proposed (and even added) these to the passdb API a little
> > while back.  Do you think that's still a viable solution?  If we
> > implement the 'ldap trust uids' thing (stops Get_Pwnam() inside ldap)
> > then this would certainly scale much better than existing code.
> 
> Well as I said before we should make a generalized api, and not to be
> forced to use ldap.

Yesp.

> About trusting the storage I see no problems, in the case of ldap you
> may use it as idmap storage and implicitly trust it. But user account
> lookup is a minor issue imho, I do not mind if 2 calls are made (one to
> retrieve the account and one to retrieve the mapping), if you can
> optimize, then better for you.
> What we stress idmap with is really file system acces check and ACL
> handling, so it need to be *fast* (and I'm not sure ldap is the right
> place for that in this regard).

Yes, I've noticed this.  'hide unreadable' is unusable on an ldap
backend at the moment :-(.

> I would like to use an internal tdb to do that, the fact that the api
> currently have the uid->sid dis->uid call is because at time we had
> alghorithmic rid mapping and in the move towards free sid mapping it was
> an easy place to do so (and make you easy to "optimize" things with
> ldap). However in case of ldap, I would like to see a different approach
> for speed, I woul like to see a way to use the tdb to read mappings, and
> a slow path in case we set a new mapping and have ldap, in this case we
> may set the map in ldap, and then cache it again in tdb to handle
> retrievals, so that only writes are slow.

Yep, that sounds worthwhile.  We could even just make it a timeout - and
finally put gencache to use :-).  (mimir's generalised tdb cache).  

> But to use ldap as a central storage you have to solve how to handle
> foreign or builtin/special SIDs!

Well, I was only looking at mapping our own domain - I was thinking the
rest should happend via winbind.  However, it does make more sense that
this is all handled in one place.  I think we can deal with this.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net