libmsrpc for Samba 3

[Chris Nicholls]

Gerald (Jerry) Carter wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Chris,
>
> Let's keep this on the mailing list in case others
> want to jump in.
>
> Chris Nicholls wrote:
> | Gerald (Jerry) Carter wrote:
> |>
> |> The first place to start I think is to figure out how
> |> libsmbclient and libmsrpc will work together.  Obviously,
> |> we'll need libsmbclient for the initial connection
> |> and named pipe support.  What is the division between
> |> these two libs?
> |
> | Since MS-RPC is essentially above SMB it seems
> | like the natural seperation would be for lbmsrpc to
> | sit on top of libsmbclient, so libmsrpc would call
> | the necessary functions from libsmbclient to get the
> | job done, but not vice-versa.
>
> Correct.  let's ignore rpc direct over tcp since
> we don't have it in Samba 3 anyways.
>
> | I'm still trying to wrap my head around if/how
> | this would be possible technically.  However, a
> | problem with this approach is that it might
> | not offer seamless integration with the
> | code that is already around.  If an application is
> | calling a function in libsmbclient expecting it to
> | make the right call (RPC or otherwise) then it might
> | be wise to have libsmbclient call the necessary
> | functions from libmsrpc.  I need to study the code more
> | to get a better sense of how libsmbclient is used but
> | i'm just wondering if you have any thoughts on this?
>
> I think it is best to make a fresh start here.  For example,
> if an application wanted to enumerate shares on a
> server and currently used a RAP call (and thus were limited
> to share names <= 12 character in length), the application
> would need to be modified to take advantage of the
> newer rpc srvsvc calls.
>
> One question that arises in this model though is what
> initialized structures does an rpc connection require
> and what does the library take care of itself.
>
> Currently in Samba's client tools one layer initializes
> the connection (session setup and tcon to IPC$) before
> passing the cli_state* to the rpc calls.  Is this the
> right model for application writers?  Probably not
> since it requires too much knowledge of the network
> protocol.
>
> What are the other alternatives we have here?


At first glance, I thought a structure like SMBCCTX might be a good 
idea. However, I think libmsrpc will have groups of functions that are 
not closely related to each other (ie. winreg vs. srvsvc vs. eventlog 
etc. ) so it doesnt make much sense to keep references to all of them in 
one structure.  Really only a small amount of data will have to be 
stored in a structure in the application itself. Basically client 
Netbios name, workgroup/domain, username, and perhaps some space for any 
variable data that needs to be stored and maybe some server information, 
but it seems like the server information isn't required.  I believe all 
of the authentication and state information can be stored in struct 
rpc_pipe_client (unless i've misinterpreted it's use) and cli_state.

I agree that the application should store as little information as 
possible and let the library handle dealing with the cli_state stuff, 
much like libsmbclient does, using a server cache to keep track of the 
cli_state structure. As you said, the library will be much easier to 
work with as developers won't need to worry about the network protocol 
specifics.


>
>
> | I took the approach you suggested, and started by
> | commenting out #include "includes.h", i then
> | created a new header file rpc_includes.h  which
> | would #include any necessary headers to compile
> | the rpc_client code, from the list I found that
> | the following header files are necessary for compilation:
> |
> | xfile.h
> | nt_status.h
> | pstring.h
> | talloc.h
> | privileges.h
> | ntioctl.h
> | local.h
> | nterr.h
> | byteorder.h
> | smb.h
> | ntlmssp.h
> | rpc_creds.h
> | rpc_misc.h
> | rpc_dce.h
> | client.h
> | safe_string.h
> | rpc_client.h
> | secrets.h
> | mapping.h
> | passdb.h
> | nt_printing.h
> |
> | a number of these header files are included to resolve
> | dependencies in other headers, but i guess there's not
> | much that can be done about that. Also, since I was
> | avoiding includes.h I had to copy over some necessary
> | definitions from includes.h (I've included rpc_includes.h
> | in case you  want to take a look at what was needed
> | from includes.h),  I'm not too sure what the fate
> | of the rpc_includes.h file will be, but for the sake
> | this exercise I think it's alright that some
> | definitions were copied over.
>
> We may need to split these headers up some more.
> passdb.h, nt_printing.h, and secrets.h should be
> more server stuff and not really something we want
> to include for client apps.  This is a good start
> though.  It's actually shorter than I expected.
>
> Redefining a few necessary macros is probably acceptable
> if it is at least manageable.
>
I'll look into this and see how much needs to be redefined to make it 
work.  I should be able to get that done tonight.

> Looks like a really good start.  Go ahead and create a
> source/libmsrpc/ directory in the SOC/SAMBA_3_0/ svn branch
> so we can start sharing code.  I'm not tied to the rpc_client/*.c
> interface so if you want to think about a better interface
> client for this client lib, that fine.  Or if you think the
> current interface is ok, then we can start with that as well.
> I think we'll probably end up modeling a lot of the corresponding
> interfaces in MSDN here.

I'll add the the rpc_includes.h and rpc_proto.h, along with the quick 
and dirty makefile to the source/libmsrpc/ directory for the moment and 
get that commited to svn tonight once I widdle down the headers a bit.

As for the interface I'll have to put a bit more thought into it. I 
think the current interface is ok for the moment but I figure once I get 
a little deeper into it i'll have some good ideas.

Chris

> cheers, jerry
> =====================================================================
> Alleviating the pain of Windows(tm)      ------- http://www.samba.org
> GnuPG Key                ----- http://www.plainjoe.org/gpg_public.asc
> "I never saved anything for the swim back."     Ethan Hawk in Gattaca
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFCzBACIR7qMdg1EfYRAsaJAJ4iFR83Lb7vhcK6vPbllNoudtE+uQCfbrRd
> 0mV+hprE5qZIYRcsY0W2gAI=
> =h1mu
> -----END PGP SIGNATURE-----
>