[samba-tng] status: nt5ldap and samtdb

[Cole, Timothy D.]

> -----Original Message-----
> From:	Luke Kenneth Casson Leighton [SMTP:lkcl at samba.org]
> Sent:	Monday, January 31, 2000 2:46
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	[samba-tng] status: nt5ldap and samtdb
> 
> decided lst week to abandon the old (1 year old) passwd db api.
> 
> luke howard is implementing an nt5ldap password database.  i'm
> implementing a samtdb.  the idea is to encourage luke to work with the
> SAM-defined api, but he's waiting for me to get into samtdb, first.
> 
> i have the following functions up-and-running:
> 
> sam functions:
> 
> _samr_connect
> _samr_connect_anon
> _samr_close
> _samr_enum_domains
> _samr_lookup_domain
> 
> domain functions:
> 
> _samr_open_domain
> _samr_enum_dom_users
> 
> user functions:
> 
> _samr_create_user
> 
> 
> _samr_create_user is hard-coded, i need to do a RID-cycling function.
> actually, tim, i need that libsurs really badly!  we also have a
> chicken-and-egg problem.  a lookup to create an NT user requires a unix
> user, first, but no lookup in the surs table is going to help resolve
> users that don't exist in the NT user database if you haven't added them
> yet!  agh!
> 
> i am somewhat at a loss on this one.  i wouldn't mind if it wasn't for
> having to deal with both mathematical _and_ database-based surs table
> implementations.
> 
> if you think it through, there's an atomic-operation problem (i.e any
> possible algorithms aren't atomic in updating both the surs and the SAM
> database).  oops.  not going to think about it now.
> 
> ok, i thought about it.  i think the solution is to have the surs table
> have an extra parameter:  BOOL create
> 
> i.e if the SID doesn't exist, then create one in the table.
> 
> mathematical surs tables, that's trivial: all SIDs (in their limited space
> because the uid/gid space is only 32 bit) already exist, therefore
> creation is trivial.
> 
> table-based ones, that means that the table must create the unique SID.  i
> suggest that the first few components of the SID be used as the base, and
> the newly-created RID be concatenated on the input SID parameter.
> 
> either that, or just create a new function surscreatesidfromposix().
> 
	Ohh... dammit, I was hoping I wouldn't have to get into this... :P

	Um, it's probably best done in a separate functions, because there's
too much semantic difference depending on if you specify create or not...
I'll think more about this when I get home.