Observation/Question on use of NTSTATUS in the Samba4 code base

[tridge at samba.org]

Krishna,

 > Do you plan to support acf files? Especially,  the notion of
 > explicit/implicit/and automatic binding handles?

I don't have any plans to do any work on ACF files myself, although
Jelmer might (Jelmer is the maintainer of our IDL compiler, called
pidl).

 > One thing I find interesting is the Samr calls start with an handle open
 > SamrConnect(,..,.., [out,ref] policy_handle *handle).

yes, and I'm very glad they do :-)

 > Given that the NetAPIs (which wrapper the Samr calls) are basically
 > stateless calls

no, they are not stateless. They give an illusion of no state, by
hiding the state inside the wrapper implementation. If you look on the
wire, I think you'll see that underneath the win32 code is actually
keeping some open handles.

I far prefer an API where the caller explicitly knows which handle he
is passing to what function, rather than having the function grab a
handle from some static variable. This is especially important in test
suites, where we want to deliberately pass bad handles (like a LSA
handle to a SAMR function) to ensure that we are doing correct handle
validation in our server implementation. 

Even outside of testsuites I think it is much better programming
practice to make the handles explicit.

 >, why would the Samr calls need a context handle (I'm
 > wildly speculating that policy_handle is an RPC application context
 > handle - correct me if I'm wrong)

Look at something like samr_OpenDomain(). A user can open multiple
domains at once, thus opening multiple handles. Each of those handles
can even be opened in a different security context. If we didn't pass
a handle explicitly to functions like samr_QueryDomainInfo() then how
would we know which of those open handles to use?

 > I guess the general reason is to maintain the access rights after you do
 > a security descriptor check the first time.  But then that information
 > needs to be communicated back to the calling client which would need to
 > pass it in as a parameter -- which the NetAPIs don't provide??

right - the NetAPIs don't allow you to do many things that can in fact
be done with the RPC calls. We can't assume that all users will be
using the NetAPIs however. A attacker might send us raw RPC requests
to exploit a bug - and we need to be sure we can handle anything that
can be sent over the wire.

Cheers, Tridge