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 Sun, 24 Jun 2001 17:05:17 GMT
On Sat, Jun 23, 2001 at 06:57:59PM -0700, Roy T. Fielding wrote:
> > NT already _has_ NT namedpipes (and so does OS/2).  so,
> > you are proposing to 'shackle' the NT named pipes to 'local only',
> > because some unix developers can't be ... well ... uhh...
> > okay, i'll be polite, but it's the same thing, 'might be confused'
> > by something that isn't a unix API.
> 
> No, that is complete bullshit and I want all of the Windows developers to
> know that this type of argumentation is juvenile and isn't appreciated.

uhhm... well, uhmm, sorry, i wasn't to know that's how it would
be interpreted: it didn't look like it to me, otherwise i
would have said something else, neh.

hm, maybe... yeah, i was using reducto-ad-absurdum and
then connecting that to implicit criticism of unix developers who
may consider unix to be 'better' because it's not nt.

nt does have some extremely well-designed apis, that are
then rushed to market and botched in places.  a great pity.
_and_ they have a monopoly, which tends to wind _everyone_
up.


> The purpose of APR is to provide a portable runtime.  If a function only
> exists on Windows or OS/2, then use the native library for those functions.
> If there is a specific behavior that you want to replicate on all machines,
> then define the feature set -- I don't give a rat's ass if it already exists
> in Win32, if you can't define what the features are then we can't bloody
> well make it multiplatform (on the platform that has already implemented
> the feature set, we will use the native calls).  If the Windows name
> happens to match an existing Unix name, the Unix name wins because that
> is the most likely platform for developers and client implementations of APR.
> So choose another name for the feature set if the features don't match
> those under Unix.
 
hm.  i'll have to think and get back to you.  it is
v. unfortunate that there is a named pipe on both NT
_and_ unix, and they do different things.

because here, the unix equivalent isn't _capable_ of
doing anything _like_ as much as the NT equivalent.

my point of the [reducto-ad-juvenile-conclusion] comments
above were to say, well, if you have the same names, but
different functionality, why would you want to limit
the [apr] functionality to that of the least-functional
api?

so yes, changing the name for the apr equiv
seems like an extremely sensible thing to do, here.
it's caused enough hassle here already just discussing
it!

[and btw the points about lowest common denominator _do_
make sense to me, and i _do_ respect them].


how have such name/functionality conflicts been resolved
in the past?


the feature-set i need is very simple:

- transaction and security-context passing between
platform-independent, location-independent clients and servers.

that means, in NT and OS/2 API terminology, the full
functionality behind:

CreateNamedPipe
TransactNamedPipe

in unix terminology, there _is_ no equivalent (unix is
somewhat backward in this respect, being about 10 to
15 *years* - not man-years, _actual_ years, behind NT,
and i'm not kidding here.)


...tell you what, i will write up an API proposal and
morph some code to an apr api.  less talk, more code :)


> > i think that anyone looking at such a codepath, trying
> > to work out what's going on, is going to do a double-take
> > and get even more confused than if the nt impl. of apr_namedpipes
> > just went straight through to the NT one and the unix one
> > used some external proxying service to emulate the remote bits.
> > IF they WANTED the remote bits.
> 
> That would be opening a security hole, just as UNC are security holes.

and that is the choice of the user of the application, and
we know that.

i am not sure what your background is, or that of the other
people on the list.  i worked for ISS for 18 months, and had
security principles drilled into me.  one of them was that
security is a trade-off between functionality and risk.

the best network security is an air-gap [unplug it!! :)]

however, in practice, this is regarded as impractical and
only a partial joke in the security community (paranoia rules), and
so everything you do from that point onwards is a calculated
risk.  not many people actually bother to assess those risks,
or are even aware of them, and it seems that you do, and are.

so, that having been said, i am fully aware too of the risks
of providing remote services - i've been developing them
for five years.

so, your point is noted, and my question is, is it enough to
stop apr from doing it [NT-style namedpipes]?

best regards,

luke


Mime
View raw message