more to come

Jeremy Allison jallison at
Tue May 5 19:03:53 GMT 1998

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

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

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



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

More information about the samba-technical mailing list