password API needed

[Luke Kenneth Casson Leighton]

On Wed, 20 May 1998, Luke Kenneth Casson Leighton wrote:

> ok: i've just added code that allows "optional" support for get/add/mod -
> smb_passwd or sam_passwd functions.  there are three get, one add and one
> mod set of smb and sam21 functions.
> 
> if neither are supported by the back-end password database, a run-time
> warning is generated.

oops, just spoke with jeremy: vector function tables with NULL entries are
bad programming practice.  therefore, this is going.  all functions will
be expected to be supported: some of them will be "stubs" which call the
conversion routines from the module.

in this way, support for either smb_passwd or sam_passwd (or both, should
the module writer wish) will be provided. 

 
> i also reverted some code that immediately converts rids to unix uids,
> inside the lib/rpc code.  i do not believe that this is a good idea: it
> places a restriction on all password database systems that there must
> exist a monotonic mapping of unix uids to nt user rids, in order to do
> proper lookups by rid (which is unique).
> 
> the limitation (restriction) inherent in one password database system,
> because it does not support rids and has to use pdb_user_rid_to_uid()
> should not be imposed on the samba domains code, in my opinion.

ok.

jeremy reckons that this will lead people to think that it's ok to use
rids not uids, which will lead to problems.  e.g, abusing the "map
username = " function to map all NT users to the same unix user.  BAD.

i reckon that you will end up with several instances (currently about 
five) where rids come in, they immediately get converted to uids and
getxxxxbyuid() is called, instead of a single call getxxxxbyrid().

therefore, this whole thing (rid<->uid) is still up in the air, and we
really need a high level conference to sort this out.