more to come

[Jeremy Allison]

Luke Kenneth Casson Leighton wrote:

> this is a known problem that needs to be addressed by _not_ having a
> function that returns by unix uid but returns by NT RID:  NT RIDs must be
> unique.  then if the unix uid is needed, you call nt_user_rid_to_unix_uid.
> 
> none of the NT dce/rpc functions look up by unix uid, so this issue goes
> away.
> 
> jeremy this is also exactly why the get_smbpwd_entry_by_uid function must
> be get_smb_entry_by_nt_rid.
> 

No I disagree. Remember - THERE ARE NO RIDS IN THE smbpasswd FILE !!!!!
(Sorry for shouting but this is an important point). Do not
mix uids/gids/RIDS together.

There are only names and unix uid's (and it's rather debatable
whether there should be uid's in there :-). This means it is not
possible to make the call you suggest. Also it's not desirable
to have RIDs in there. In the UNIX space RIDs are an artificial
concept - you must map to them uid_t's or gid_t's.

Do your uid/rid mapping at a layer *ABOVE* the smbpasswd file -
eg. do rid_to_uid_or_gid(), then depending on whether it
came back as a uid_t or gid_t then look it up in the 
relevent UNIX database.

The problem that Jean-Francois is referring to is that
a single UNIX uid_t may map to more than one name. Well,
tough - that's the semantics of the UNIX database (and
most UNIX implelentations will return the first entry
on a uid to name lookup). This means that for a two given
names, mapped to the same uid_t, the RID will be the same.
If you don't like it then don't set up the UNIX database
that way. I'm not going to add artificial constraints to
the semantics just to impose the artificial constraint
that 'all RIDS *must* be unique' - that's just not the 
way it is in UNIX, so lets live with it :-).

Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------