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:18:41 GMT
On Sat, Jun 23, 2001 at 01:47:54PM -0700, Justin Erenkrantz wrote:
> On Sat, Jun 23, 2001 at 09:49:16PM +0200, Luke Kenneth Casson Leighton wrote:
> > i actually know very little about named unix pipes.  but afaict,
> > yes, _unix_ named pipes are a local-only concept.
> > 
> > and i advise against using unix pipes to implement this proposal,
> > which is to implement *nt* named pipes, which are, as you
> > can see from the OS/2 and NT developer SDK documentation, are
> > totally different from un ix named pipes.
> Okay, maybe we should come up with another name besides named pipes.
> It is obviously confusing the hell out of us Unix people.  This is
> obviously something other than the named pipes most of us are familiar
> with.

yesplease! *out-of-my-depth here*

> I guess my attitude is, "show us the code."  But, please don't call 
> it named pipes.  =)  Remote pipe or something.  Once we see the code,
> then we can provide more concrete feedback.


well, there are two examples.

unix_sock.c as used in http://virgule.sourceforge.net.

client-side usage is in mod_xvl/, and server-side is in

but that is a cut-down version of the code in TNG, it
does local-only.

you can see that it uses unix domain sockets, and that
there isn't any security, which i _am_ going to have to
re-add, because i now use the code to obtain user-passwords,
in mod_auth_xvl.

that's a simple matter, but it will need auditing - by
an experienced unix systems developer, which i _know_
i am not, and not afraid to say so.

> If you already have a Unix-based implementation of remote named pipes 
> (seems that it is in Samba - but be aware of the GPL/BSD issue - ASF 

TNG only.

> can't use code derived from Samba unless *you* are the copyright 
> holder), 

which i am.

> I'd guess that it wouldn't be too hard on your end to at 
> least post a patch/code (within APR framework) that illustrates what 
> you are talking about.  
ack.  well, a _quick_ one is simple, you are right.  about...
1 days' work?

a more complete one?  with a 'clean' way to transfer
security context?  and the code _does_ need a security
audit, which i even print out this fact into the
log files :) :) about a week.

> This code might have some potential usefulness for stuff we are doing
> here (it could save us the overhead of implementing/using RPC).  So, 
> I'd definitely look at it - and depending upon how it works, I might 
> even use it, too.  =)  -- justin

coool :)


View raw message