more to come

Luke Kenneth Casson Leighton lkcl at
Tue May 5 18:06:12 GMT 1998

On Tue, 5 May 1998, Jeremy Allison wrote:

> 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 !!!!!

i know!

then there either:

- should be (rids in the smbpasswd file)
- rids should be automatically generated (and made to be unique, even when
/ if two users are stored with the same unix UID).

i know you're putting in a mechanism to give trust accounts a unique uid,
counting down from 65534, but if someone uses "map username" to map
multiple trust accounts (manually) to the same unix uid (e.g the guest
account) then we are in trouble.

> (Sorry for shouting but this is an important point). Do not
> mix uids/gids/RIDS together.

no "mixing" is intended.  in what way do you conclude that uids/gids and
RIDs are being mixed?

> 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.

we _have_ to have RIDs: you can't implement LsaLookupRids, LsaLookupNames
and SamrQueryDisplayInfo without them.

these all assume that RIDs are unique, and more importantly _not_ unix

> 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.

using this method you lose the one-to-one mapping, as for example when you
receive a SamrQueryDispInfo call, you enumerate through all RIDs and do:

for (rid = get_first_rid(); usr; usr = get_next_rid())
	uid_t unix_uid = rid_to_uid(rid);
	SAM_USER_INFO_21 *usr = get_smbpwd_by_unix_uid(unix_uid);

this is flawed: you have already lost several entries, namely those that
have the same unix uid.  even if you were to use get_first_smbpwd_entry();
get_next_smbpwd_entry() and fill in the rid, you would end up with a set
of non-unique rids when you did the reverse-lookup (uid_to_rid), which
would cause you to come up with the wrong user in USRMGR.EXE or

> The problem that Jean-Francois is referring to is that
> a single UNIX uid_t may map to more than one name. Well,
> tough

yes, it's tough, and we have to deal with it.

> - 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 :-).




ok.  let me attempt to clarify.  the API should work by RID.  the
underlying implementation of smbpass should be by unix uid.  is that
acceptable?  (because it's what i'm trying to tell you what i would like
to work towards!)


More information about the samba-technical mailing list