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@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.
p.s. the win32 port of samba tng was originally done for wine - and reactos's - benefit. and because it'd just be utterly one-in-the-eye to be able to turn something like a P.O.S windows98 box into a Primary Domain Controller ha ha :)
On Friday 30 January 2009 19:38:20 Luke Kenneth Casson Leighton wrote:
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.
Funny enough, the Samba project codenamed "franky" (http://wiki.samba.org/index.php/Franky) will be doing all of this. It's not quite there yet, but after some nice work done in the Samba3 smbd by Volker Lendecke and some more work in the Samba4 "samba" daemon by Stefan Metzmacher, Jelmer Vernooij and some overall effort by other folks from the Samba Team, franky is coming along quite well.
Just a heads up, Kai
On Sat, Jan 31, 2009 at 9:50 AM, Kai Blin kai.blin@gmail.com wrote:
On Friday 30 January 2009 19:38:20 Luke Kenneth Casson Leighton wrote:
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.
Funny enough, the Samba project codenamed "franky" (http://wiki.samba.org/index.php/Franky) will be doing all of this. It's not
HOOORAAAAAY!
time for a celebration.
nearly a decade waiting for that stuff.
that's really good news - thank you, kai.
Funny enough, the Samba project codenamed "franky" (http://wiki.samba.org/index.php/Franky) will be doing all of this. It's not quite there yet, but after some nice work done in the Samba3 smbd by Volker Lendecke and some more work in the Samba4 "samba" daemon by Stefan Metzmacher, Jelmer Vernooij and some overall effort by other folks from the Samba Team, franky is coming along quite well.
kai, thinking about this some more (hi volker, nice to see you're still working on this stuff!) i just want to emphasise a few things:
1) i really am absolutely delighted that a break-out mechanism has been added to samba, for many many reasons
2) you will also need to add a break-out mechanism for the entire IPC$ channel, along the same architecture lines, for exactly the same reasons. wine and other systems have their _own_ implementations of NetUserGetInfo and other functions; in combination with the code in cliffsd (which is again public domain and was written from taking the IPC spec document and using it as an IDL file!) it will be possible for wine add IPC$ functions to WineServer with minimal coding effort on the part of the Wine Developers.
the way that i implemented this (or maybe planned to - looking at the code i don't see it. odd. oh well!) in samba tng was to create a daemon called "lanmand", which received an authentication context "blob" (effectively a marshalled NET_USER_GET_INFO_3 structure aka a SAMR_USER_INFO_21), and the functions where the "break-out" occurred were on SMB_TransactNamedPipe, SMB_ReadX, SMB_WriteX and SMB_Close on anything that's an IPC$.
think about it: the wine team have to get notifications to wineserver of events such as WaitNamedPipeState, SetNamedPipeState etc. etc. and the only way to do _that_ properly is if they receive proper notifications.
it's made a little more complex unfortunately in that _some_ of the data needs to go to the LANMAN break-out mechanism, and _some_ of the data needs to go into the DCE/RPC IPC$ stuff.
ohhh, no it isn't: it's actually very simple: i forgot - there's a PIPE named LANMAN, isn't there? :)
so, actually, it might be simpler than i thought, in that WineServer could simply have its own LANMAN pipe service (bypassing the one that's hard-coded in smbd).
... you'll work it out :)
3) the strategic importance of the "break-out" mechanism cannot be underestimated.
by not implementing a break-out mechanism for all these years, samba has effectively been operating under a "proprietary implementation" shadow, made all the more worse by the fact that the source code is GPL'd and so it _looks_ like it's free software.
free software projects, as the trolltech code base and other examples showed by being effectively a "one-way-push" instead of a "collaborating encouraging community project", are not just about "freeing the code", when it comes to multi-man-decade efforts such as samba, wine, reactos etc. it's your _responsibility_ to ensure that there are interfaces where other projects can interoperate.
otherwise, you are doing _exactly_ what microsoft has been doing - shutting the door in people's faces by not allowing them to interoperate along clearly-defined interface boundaries.
and that's the primary reason why i was so pissed off with what was going on in samba. you weren't just shutting out samba tng by not adding in the break-out mechanism, you were shutting _everybody_ out - wine, reactos, embedded NAS storage devices, sun microsystems, _everybody_ who wanted to use smbd's expertise as a service that could be improved on _every_ single one of them was shut out - and thus you've been _pretending_ to serve the free software community....
... up until now, when you are now, finally, _actually_ serving the free software community.
which is why, and i cannot say this enough times, nor emphasise it enough, that it's such a big damn deal to have this interoperability interface.
so - keep it up, and xxxxing well done!
oh - did andrew bartlett complete that authentication plugin interoperability interface? because that's another critical / crucial area that needs to be .so dynamically-loadable (a la pam) so that it can be "broken out of", as well. wine and reactos will need that at some point (actually, they'll probably need it at exactly the same time as implementing a \PIPE\LANMAN and \PIPE<generic_service>)
l.
Funny enough, the Samba project codenamed "franky" (http://wiki.samba.org/index.php/Franky) will be doing all of this. It's not quite there yet, but after some nice work done in the Samba3 smbd by Volker Lendecke and some more work in the Samba4 "samba" daemon by Stefan Metzmacher, Jelmer Vernooij and some overall effort by other folks from the Samba Team, franky is coming along quite well.
http://wiki.samba.org/index.php/Franky/Notes_20080508
how veery iiinteresting.
i see that the justification for adding proper named pipe break-out isn't to do with inter-project cooperation, at all - it's to provide a samba3 - samba4 migration path, utilising components from each.
by fortunate coincidence, it so happens that the exact same reasons and near-exact same architecture as required for samba3-samba4 interoperability is exactly what's required for every other project that also wants to use samba as a service not as _the_ be-all-and-end-all service.
just make sure you add an SMB SetNamedPipeHandleState function to the list of callbacks / capabilities, not just createpipe, readpipe, writepipe, transactnamedpipe and closepipe.
in samba, the _only_ operation you will ever see on-wire, is SetNamedPipeHandleState to 0x3 (PIPE_MESSAGE_READ | PIPE_MESSAGE_WRITE).
but other systems will want to use franky-breakout read, franky-breakout write, franky-breakout transactnamedpipe in NON-message-mode.
and also make sure that the namedpipestate flag on the initial SMBcreateX is also passed over to the franky-breakout-create-pipe function.
oh, and a franky-breakout-get-namedpipe-state too. which probably maps to an SMB IPC$ ioctl somewhere. needs analysis.
rob, you'll want to put these on your list of things to keep an eye on:
1) franky-create-pipe receives PIPE_MESSAGE_MODE flags on/off 2) franky-set-namedpipe_handle_state function exists 3) franky-get-namedpipe-handle-state function has to exist somewhere.
all of them will be necessary for the "existing" wine apps to work correctly over-the-wire because that's what wine presently only supports: non-message-moded named pipes.
l.
-
Kai Blin -
Luke Kenneth Casson Leighton