apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: [PATCH] Some named pipe hacking...
Date Sat, 23 Jun 2001 19:10:01 GMT
> Hi Luke,
 
hi aaron :)

> IMHO, it is important to keep local and remote semantics distinct. Local
> and remote services (by services I mean any form of IPC) are inherently
> different beasts. If we allow named pipes to handle both local and
> remote connections under the same conditions (errors, assumptions, etc)
> than we may run into serious problems with reliability, error recovery,
> and we may even expose ourselves to security risks.
 
reliability and error recovery are not the responsibility of the
[remote] API.

all applications - all the good ones, anyway - that i know of
that use namedpipes or dce/rpc, pass error handling up to the
application, for the application developer to deal with.

in dce/rpc, this is even negotiable!!!  you specify in the
idl file 'i don't want to receive network errors', and well,
you don't!

security.  well, yes, as soon as you get into distributed
applications, your security risks go up.  i am familiar
with a fair number of the kinds of nightmare situations
that can occur, having discovered and reported on large
numbers of them to microsoft, until it got boring, there
were so many.

so, it's fair to assume that i've seen enough [an implementation
of remote named pipes - the one in NT - that passes a buffer size
in three separate locations, used one of them to check
the received write size against the other, and the third
one was the one used to allocate the data that the other
one copied into.  and this all in kernel-space...]

> If you really want to start handling remote named pipes, I am more in
> favor of something like what Justin suggested. That is, perhaps adding
> new functions for the specific handling of remote named pipes.

if i was to insist, and people decided, um, well, we're not
going to do it, 'cos luke's getting stroppy about it, well,
then the most sensible thing for me to do would be to say,
okay, go ahead: dunna bother me, and when - or more hopefully -
_if_ it's noticed later it dunna do what's expected, well
i help redesign.  and if it works, well, it saves me some
hassle and some typing!

all best,

luke.

p.s. i now have three apache modules that are using code that
could be used as an early version of the unix apr_namedpipe()
code.  i haven't been able to split them into separate
directories, not least because they are only 300 lines each,
but because the effort of putting them in separate directories
and then creating a mini-library for them is not justifiable.

Mime
View raw message