more to come

[Luke Kenneth Casson Leighton]

On Tue, 5 May 1998, Jeremy Allison wrote:

> Luke Kenneth Casson Leighton wrote:
> > 
> > 
> > ah.  sorry: i didn't explain.  i was presuming that one of two (three)
> > things could occur:
> > 
> > 1) we could add an independent database which did ACL support for us, and
> > its indeces would be based on RIDs (and rid_to_uid would have to be
> > called)
> > 
> 
> Bleeeeechh - that's what AT&T's advanced server for UNIX
> does - have you any idea how *slow* that thing is :-) :-).
> 
> > 2) the free oses have RID support added to them, particularly as NTFS
> > support looks like it's being added to Linux
> > 
> 
> Yeah, but they won't be RIDs - 'cos none of the other
> API's in POSIX take RIDs - they'll be uids translated
> to RIDs (sound familier yet :-).
> 
> > 3) samba gets ported to NT.
> > 
> 
> Well then we'd have to map RIDs to uid/gids for all the
> other Samba code to work - we just map them back at
> the lower layer :-).

i know: this would be _such_ a bitch...

there are other areas where i expect a uid_to_rid call one one side of the
proposed API to be followed immediately by a rid_to_uid call, but only for
_some_ of the compile-time password database options (most likely the
smbpasswd one).

 
> > 
> > ok, there's another [technical, coding] reason why it is a better idea to
> > delay the conversion from rid to uid for a small amount of time: namely
> > that within all dce/rpc calls that reference RIDs (of which there are
> > several, and there will be several more) you will need to make a
> > rid_to_uid call.  i am unhappy that this will have to be done, when i
> > percieve that it would be better to have the API layer _below_ make the
> > rid_to_uid call.
> > 
> 
> This is a good idea - we should structure the uid->RID mapping
> so it's above the dce layer, except when the dce layer needs
> to enumerate uids/gids - then the map to RIDs should be done
> within the dce call.

yes!  hooray.
 
> > i'm not asking to abandon uid_t / gid_t in _favour_ of RIDs, just to think
> > of the dce/rpc code as operating at the level it ought to (namely, by
> > RID).  it's NT code, not UNIX code, remember.
> > 
> 
> Ok - sounds good to me. So long as RIDs don't bleed into
> the other parts of the Samba code (more than they have to :-).

brilliant: i agree with this.  kick me if it happens!  the only place i
can think of that RIDs would need to be _stored_ but not _used_ (except by
the dce/rpc code) is in the... um... vuid struct user_info, for
some of the \PIPE\srvsvc functions (i think).

so, i think there was a misunderstanding that we've finally identified:
that you expected me to be saying that all the existing UNIX code
(server.c) should convert to RIDs.  no, most definitely not.

radical.