http://wiki.winehq.org/NamedPipes

[Luke Kenneth Casson Leighton]

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