CVS update: samba/source/msrpc (fwd)
Nicolas.Williams at wdr.com
Fri Jan 21 18:29:54 GMT 2000
On Sat, Jan 22, 2000 at 05:08:13AM +1100, Luke Kenneth Casson Leighton wrote:
> On Fri, 21 Jan 2000, Nicolas Williams wrote:
> > 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:
> > - 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
But storing that in a tdb keyed by <PID, vuid> as I suggested below
would save you the trouble.
> > - 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().
So that falls under the "various information" clause I used below. Put
it in the tdb record indexed by <PID, vuid>.
Why write the same data many times?
> > - 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?
Hmmm, so you pass SMB packets to the DCE/RPC daemons? Wouldn't it be
easier to just pass the [reassembled] DCE/RPC payload? That would
simplify the DCE/RPC daemon code base. It may be too late for that
> > - 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
> 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.
> > 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.
So? At least this leaves the door open for a future asynchronous or
> 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.
Just leave the door open.
> > 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!
That limit varies from platform to platform. Anyways, Samba isn't ready
for threading, though that could come on a daemon by daemon basis if the
IPC system you use leaves room for it (i.e., SMBD processes should talk
to a master daemon for each DCE/RPC service -- let that master daemon
choose to fork(), pre-fork(), thread, whatever.
> 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.
I'm glad to be of [cheering type] help :)
-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