CVS update: samba/source/msrpc (fwd)

[Luke Kenneth Casson Leighton]

On Fri, 21 Jan 2000, Nicolas Williams wrote:

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

i'll review what you say / confirm.
 
> Here goes:
> 
>  - SMBD should pass DCE/RPC named pipe traffic to the appropriate
>    DCE/RPC daemon via, say, Unix domain sockets, encapsulated with the

yep.  done that.

>    following information:
> 
>     - SMBD PID

yep.  done that.

>     - client transport addresses (NetBIOS name, IP address)
>     - share name (IPC$)

i'm going to have to do this, and it needs to be _much_ more than just
this.  from standard_sub_basic():

- local_machine
- remote machine
- remote proto
- logged-in username (changes for a NetrSamLogon or a NetWkstaGetInfo!!!)
- remote arch
- pid
- VERSION string
- ENVIRONMENT variables
- client ip
- automount server
- unix username


>     - username used to authenticate to share (user, guest, null [anonymous])

yep, got that.  i also send the unix username + unix groups, to save me
having to do a getgroups() and getgrnam() on thhe othe side: why go to all
the hassle of generating more work for aan mssrpc daemon than is necessar:
it's already had to do a fork() just like smbd and we're even considering
optimising things so we don't have to do too many forks().

>     - named pipe name

yep.

>     - length of DCE/RPC data

weelll... that was the first implementation!

i discovered that if i use read_data_with_timeout(min bytelength =1, max
bytelength = MAX_SMB_DATA_SIZE) that you don't _need_ to send the length
of the DCE/RPC data.

cool, huh?
 
>  - 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.

weelll... oh bugger.  OH NO, NOT ANOTHER CHANGE TO THE SOCKET INTERFACE!

the smbd pid + the smb vuid should be sufficient to uniquely identify a
user.

so the tdb recond index can be (pid, vuid).


> This way the DCE/RPC daemons and admin/debug tools will be able to get
> at all information they might need for their tasks.

yep!

> 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()

uh... you _Are_ aware that DCE/RPC functions are exactly that: functions.
and function calls can block for an _awfully_ long time.

if you start thinking in terms of "oh, we'll have one daemon and have it
deal with multiple requests" then the consequences are that one user can
trash several other user's requests.

and i _Really_ don't want to consider doing an asynchronous implementation
of the dce/rpc client and server code, in a similar fashion to how nmbd
works.  i _know_ how nmbd works, i wrote the second implementation (and a
third intermediate one that was never used, which pissed me off) and it
took months to plan the data structures and two years to implement fully
and three people to work on it.

so no, i don't want to go down this road.  i'll make it as easy as i can
for someone _else_ to do this, but no, it's not one for me.

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

interesting!  sounds like something that samba ought to be doing itself!
 
> 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.

weelll... the NT implementation is much simpler.

they CERTAINLY don't totally reconfigure according to user / workstation /
type of connection the way that samba does!!!!

and they use threads.

no, no and no.  we're _not_ going to use threads in samba.  no, repeat,
no.  what's the limit on a select file descriptor set?  256?  there are
samba installations out there which peak at around 3,000 simultaneous
connections.  you think threads can cope with 3,000 connections?  i don't!

:)

lukes

nico, thanks for the comments.  it looks like i'm going to have to add the
remote vuid to the socket setup stage as well as the remove pid.