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: More migration of code from httpd to apr-util
Date Mon, 11 Jun 2001 14:38:53 GMT
On Mon, Jun 11, 2001 at 03:04:10AM -0700, Greg Stein wrote:
> On Mon, Jun 11, 2001 at 12:38:23AM +0200, Luke Kenneth Casson Leighton wrote:
> > On Sat, Jun 09, 2001 at 08:30:23AM -0700, rbb@covalent.net wrote:
> >...
> > > BTW, APR already has named pipes.  Just what are we trying to solve here?
> 
> We only have them implemented for Unix. OS/2 returns an ENOTIMPL and Windows
> simply doesn't have an implementation for it.
> 
> > i looked at the named pipe code: i believe that you are thinking
> > of 'unix' named pipes, which are a totally diffrerent beast
> > from nt named pipes.
> 
> Right. I don't recall all the bits about creating named pipes in Windows,
> but it may be feasible to use the "filename" in the
> apr_file_namedpipe_create function for the host/name of the pipe in NT. In
> other words, it may be a simple matter of writing the function for Windows.
> But then again, the function params may not be rich enough for what is
> needed.
> 
> >...
> > - a means to set up a server and have other programs (not
> > remote programs) connect to and communicate with that server.
> > 
> > the semantics must be identical to those of unix-domain-sockets,
> > namely a listen, bind, accept, read, write and close.
> 
> I would think you could use named pipes, 

don't know anything about them: are they portable?

> TCP sockets, 

known to be slow, even on 127.0.0.1 loopback.

> or Unix sockets.
 
not portable.  [would do the trick, imo, for a ux-impl. of
NT NamedPipes.]

> If the server spawns the programs, then you can also use regular pipes.
> 
> > - a means to transfer security context between
> > the server and the 'other programs'.  i.e. if the
> > client program is running as 'foo', then it must be
> > possible for the server to be 'told' this - _if_ it
> > needs to know.
> 
> I do not believe there is a way in any OS to say what *program* you are

the program is irrelevant: it's the named pipe that's important.

exactly in the same way as in ux-dom-socks, the program 
is irrelevant [i have to say, i don't quite follow
what you mean or think i meant that prompted you to
mention 'programs, here: perhaps you could elaborate
so we don't mis-communicate?]

e.g i will call pp = apr_create_np("\PIPE\xvl\xmlvl.org", pool)
and it will create, on ux, a domsock /tmp/.apr/PIPE\xvl\xmlvl.org.
i will then call apr_bind(pp), apr_listen(pp) etc blah blah.

i will then, in a client-program (mod_virgule), call apr_open_np(
"\PIPE\xvl\xmlvl.org") etc. which opens me a connection, causes
the server to call apr_connect() blah blah, in all the usual
ways.

now, on NT, of course, this will not work: NT doesn't _have_
ux-dom-sock.  but it _does_ have NamedPipes.

and i expect that using them could provide exactly the same
functionality [as described in above example].

> running (in an authenticated fashion). Reading man pages, it appears Linux
> 2.2 added a way to send another process the PID, UID, and GID. But that
> would obviously be non-portable.

the technique used in samba TNG's IPC mechanism 
[which is ux-dom-sock-based], is to transfer the uid, gid and
ux-groups [plus the NT auth equivalents as well] over the
socket as ... 'out-of-band' data at setup time.

this info is recorded in a state-structure that can be
obtained by a get_sec_ctxt() -get security context - function.

so, the impl. would be, if you detect that lx 2.2 supports
transfer like this, use it.  if not, send the uid, gid, ux-groups
at setup time.

simple :)

[btw, it so happens that the pid is also transferred, but that's
for other reasons that have nothing to do with emulating
NamedPipes, it's to do with SMB and the implementation
of Samba TNG.]

all best,

luke



Mime
View raw message