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.