Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 23848 invoked by uid 500); 11 Jun 2001 14:40:00 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 23759 invoked from network); 11 Jun 2001 14:39:54 -0000 Date: Mon, 11 Jun 2001 16:38:53 +0200 From: Luke Kenneth Casson Leighton To: new-httpd@apache.org, dev@apr.apache.org Subject: Re: More migration of code from httpd to apr-util Message-ID: <20010611163852.D7960@angua.rince.de> Mail-Followup-To: new-httpd@apache.org, dev@apr.apache.org References: <20010609132552.B24934@angua.rince.de> <20010611003823.E2726@angua.rince.de> <20010611030410.D26210@lyra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20010611030410.D26210@lyra.org>; from gstein@lyra.org on Mon, Jun 11, 2001 at 03:04:10AM -0700 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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