dce/rpc "client" api

[Andrew Tridgell]

> take a look at api_NetWkstaUserInfo.  what parallels do you see between
> the data returned and the full NT user3 struct?
> 
> to my eye, they look pretty much the same.

My concern about the use of things like the NT user3 structure as a
central data structure in Samba isn't that it is large, or that it has
excess baggage. My concern is that it ties our internals to one
particular structure in NT. 

This might become a problem if/when NT starts using a info level 6
structure over the wire that has a few more fields than a level 3
structure. We would then either have to fake up the extra fields or we
would have to move to using a different core structure in Samba and we
would have to add translation functions for clients that ask for the
"old" user3 structure.

In some cases the simplicity gained by using the same structure in the
rpc code as we use inside our security code is worth it, but we do
need to be aware of the downside of this choice. 

Another downside is if the elements of the structure do not lend
themselves to being used to hold unix security information. In that
case functions inside Samba that need precise information might be
short-changed by a kludge to force the information into a NT format.

> however, i do realise that it is not entirely suitable to use in
> se_access_check(), which leaves a minor inconvenience of converting
> USER_INFO_3 to whatever format you and others have selected as suitable -
> without any public discussion, i might add - for se_access_check.

just to catch this before it goes too far let me make it clear that I
will not be having a public debate before each and every bit of code I
write and I don't expect anyone else to submit to this.

I only expect a (short) discussion where we are making large
architectural changes or significant changes in the existing coding
practices. Individual contributors should not expect their every line
of code to be debated - I think that would be a severe waste of time.

> so, work _with_ me to develop a suitable implementation instead of
> discarding, obseleting and reimplementing useful work.

We have a bit of a different philosophy here. I have often found that
re-implementing a short function provides a better solution (a better
piece of code) than trying to modify someone elses code to do what is
needed. 

When the purpose of a piece of code is well defined, the time taken to
write it well is often quite short. The time taken to fully understand
another persons piece of code is often longer and attempts to then
modify that code to do something a bit different often leads to a
compromise.

There are of course lots of cases where re-using code is obviously the
best thing to do and I delight in re-using code when this is the case,
but I completely disagree with the popular dogma that code re-use is
always better than re-writing the code.

In this particular case both functions look pretty clear, although
they are different enough that it is a bit of a surprise that they do
exactly the same thing. I suspect we need a good (probably randomised)
test function for se_access_check(). Maybe we could write a test that
checks the result of these two implementations against each other and
the differences would help us find bugs. Alternatively we would need a
function that remotely asks a NT server to evaluate a security
descriptor and use that to evaluate our implementaion.

Cheers, Tridge