CVS update: samba/source/msrpc (fwd)

Nicolas Williams Nicolas.Williams at
Fri Jan 21 17:27:32 GMT 2000

On Fri Jan 21 2000 - 13:03:00 EST, Luke Kenneth Casson Leighton wrote:
> god, this is a horrible one. if microsoft... never mind :) it's a design 
> issue, and there's not much that can be done about it. *sigh*. 
> hopefully, the pid i had to use can be used for _other_ purposes, such as 
> a refernce key into other databases to maintain consistency between smbd 
> and msrpc daemons' view / usage of standard_sub_basic(). 
> i have an idea. create a system to store the standard_sub_basic() 
> parameters in a tdb database under the pid of the smbd process. the msrpc 
> daemon reads the same parameters using the smbd pid id, and does any 
> standard_sub_basic() substitutions with the same values as the smbd 
> process. 
> cool, huh? what do ppl think? 

I like it.

I've not had a chance to use SAMBA_TNG so some of what I'm about to
suggest may already be there.

Here goes:

 - SMBD should pass DCE/RPC named pipe traffic to the appropriate
   DCE/RPC daemon via, say, Unix domain sockets, encapsulated with the
   following information:

    - SMBD PID
    - client transport addresses (NetBIOS name, IP address)
    - share name (IPC$)
    - username used to authenticate to share (user, guest, null [anonymous])
    - named pipe name
    - length of DCE/RPC data

 - SMBD should also maintain tdb records indexed by

   <PID, client name, share name, user name>

   tuples. The record should contain various information, including
   standard_sub_basic substitutions.

This way the DCE/RPC daemons and admin/debug tools will be able to get
at all information they might need for their tasks. This way you can
also avoid forking separate DCE/RPC daemons for each request and instead
have one process for each daemon and thus add TNG support for platforms
that don't have fork() (e.g., VMS); you can do this because the calls
passed to those daemons now have the data they need to authorize calls

Not only that, but this would provide a way to fix the oplock problem
I've had with Solaris and which I solved by using root preexec/postexec
scripts that create PID files named by <PID, client name, share name,
user name> tuples and which are used to identify (and kill) stale SMBD

No doubt this is much the way NT does it. DCE/RPC calls must be passed
to the appropriate service threads by the kernel (or whatever processes
SMB traffic) along with extra information and or handles for obtaining
that extra information through other APIs.

-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

More information about the samba-technical mailing list