http://wiki.winehq.org/NamedPipes

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri Jan 30 12:38:20 CST 2009


rob, hi,

regarding the above wiki page - there is no "obstacle".  you can use
any of the code that i wrote for samba (about 100,000 lines of code),
i released all of it into the public domain, on dec 16th, 2005.
there's enough there so that you can do an entirely "hands off"
approach, getting packets in and out using (see last post!)
surprise,surprise, emulated named pipes.

what i did for tng was to create a "packaging" system which sent
security contexts (complete security descriptors and other
identifiying information) over a unix socket. it was completely
transparent as far as smbd was concerned, which just "handed it
around" to the appropriate daemons.

i asked jeremy to add in simple support for this into main samba
several times.  the last time (dec 2005) once _again_ he fucked about,
but did actually agree that it was a good idea.

samba having "break-out" for named pipes traffic is one of those
absolutely _essential_ things that should have fucking well gone into
the samba source code a _long_ time ago. around 1998 would have been
good.  _several_ projects would enormously benefitted - including
samba - if that had happened.  sun microsystems, who bought the [well
known to be a complete piece-of-crap] port of nt to unix, AFPS, for
$USD 4m and were utterly appalled by the poor quality of the
implementation of the smb server gave serious consideration to dumping
it, keeping the MSRPC services, and riding off the back of samba....

.. via _guess what_!  a named pipe "break-out" interface.

which, of course, doesn't exist.  so they couldn't do it.  but gordon
did discuss it with me, saying things like, "y'know, if samba had a
way in to its named pipes interface..."

and guess what?  in order for you to do named pipes via samba, you
need a named pipe "break-out" interface.

guess how luke howard implemented XAD (which he sold to novell a
couple of years ago)?  he implemented a patch to samba which provided
a named pipe "break-out" interface.  that patch was released back in
about 2002 and has never been incorporated into samba.

the protocol for a break-out interface is very simple: you need four
functions ( and they can be done in as little as about 300 lines of
c-code, as a patch to samba)

1) open named pipe connection
2) read pipe
3) write pipe
4) close pipe

if you implement that in a dynamically-loadable .so, style, as a
vector table (see e.g. apache2 module interface for example) then you
can dump a .so into a directory which samba can pick up.  any data
that comes in from SMB will then "activate" the .so, call the
open_named_pipe function in the vector table, and you're away.

you release the code of the .so under the LGPL, that gets "GPL'd" by
samba, license problem is solved.

so, with a small patch to samba, the means to take control of the
direction of wine is within _your_ hands.  because the dynamically
loadable .so conforms to the "break-out" interface and is loaded _by_
samba, on demand, and the code in it is part of Wine and communicates
using Wine protocols - entirely under your control.

... you know... it would actually be a lot easier to integrate wine
with samba tng, because the infrastructure to communicate by emulated
NamedPipes already exists.  take a look at the following functions:

ncalrpc_l_connect
ncalrpc_l_close_socket
receive_msrpc
msrpc_send

all of which are in lib/msrpc-client.c - you'll see in there that
there are corresponding functions for the samba tng win32 port -
CreateNamedPipe, ReadFile, WriteFile, WaitNamedPipeHandleState,
CloseHandle etc. which will help give you some _really_ big
clue-handles to understand the corresponding "emulating" functions
using unix sockets.

you _should_ also recognise the ncalrpc_srv_get_user_creds function
and its equivalent client-side "sender" ncalrpc_l_authenticate.  these
two are a matched pair of functions which marshal and unmarshal an NT
security context [based on a NET_USER_INFO_3 structure - recognise
that one? :) it's a stub in wine - now you have some code that gives
it purpose! ]

basically after a connect (ncalrpc_l_connect) the client sends the
user creds _immediately_, and the server picks them up, and saves them
in its internal context (for later passing around etc).  also they end
up getting used to do seteuid() but as the entire protocol was used by
root _only_ it was perfect safe to do this.  the unix sockets were
protected 600 with the directory they were in being protected 755
because some unixen _still_ bloody well let you access a unix domain
socket even if its permissions were 600, all owned by root, all
services running _as_ root, so one daemon being a client passing over
a security context that told _another_ daemon running as root to
seteuid to a user's uid was no big hairy deal.

except that andrew thought that i was some sort of fucking 17-year-old
incompetent student, and he didn't like the thought of me actually
being a capable unix systems programmer.  thus, this code could be
justified as never going into samba (even though a similar
implementation was designed _by_ him for use in winbind).  _really_
interesting bit of hypocrisy going on there.  the sad thing is that
it's stopped _so_ much progress in free software, it's unreal.

anyway - you can pick up that code with:
   cvs  -d anoncvs at anoncvs.samba-tng.org:/home/cvsroot co tng

it's anoncvs - just press return

look in tng/source/lib/msrpc-client.c

btw don't be fooled into thinking that just because you're on loopback
- running samba and wine on the same machine and only processing
requests that come in or go out over 127.0.0.1 - don't be fooled into
thinking that you can throw away the security context (the
NET_USER_INFO_3 stuff) - you can't.  you _really_ need to keep it
around, and pass it back-and-forth.

so - to recap what the protocol / procedure is:


* a small .so has already been dropped into samba's lib/ directory
which has been dynamically-loaded; any SMB-based "NamedPipe" traffic
that is NOT destined for internal samba services (such as
\\PIPE\lsarpc etc) is handed to this .so. the .so, when an incoming
"ConnectNamedPipe" request is made, will direct the contents, pretty
much verbatim BUT pre-pending the security context "blob" (see above)
to any initial connects.
* any win32 programs that call CreateNamedPipe will result in a call ..


... you know what?  this is getting complex - and i'm spending quite a
bit of time writing it.  i designed this stuff, once, and it worked.
wine needs it.  samba needs it.  so, i'm really _really_ sorry to have
to bring this up - but it's a quite important point: if you can find
someone to pay for the necessary development, i'm more than happy to
do the work.  i'm also happy to help advise people on how this can be
implemented (if the above clues and directional guides aren't enough)

it's been ten years since this kind of cross-project integration
stalled: i've watched the development of wine go its way, and samba go
its way, and ntfs filesystem drivers for linux go _their_ way, and all
of these projects don't _actually_ cooperate or link together
properly.  nobody's actually _paid_ any fucking money to coordinate
and liase with these projects.  there's people paid to work on linux;
there's people paid to work on wine; there's people paid to work on
samba.

and the only people who really suffer for lack of this really
important strategic interoperability is: users.

so can we _please_ pull our collective fingers out of our arses, get
some sponsorship and funding from _somewhere_ and get moving?

that last said with the utmost of respect :)

l.



More information about the wine-devel mailing list