You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Bill Stoddard <bi...@wstoddard.com> on 2001/06/20 22:22:54 UTC
[PATCH] Some named pipe hacking...
This is NOT ready to be committed and in fact it may be a complete waste of time. I had a
few minutes to hack around a couple of days back and came up with this. I did not even
attempt to compile the unix implementation of ap_file_namedpipe_create() much less run it.
The Windows implementation of ap_file_namedpipe_create() seems to work
I am posting this because I will unlikely have time to work on this for quite a while and
wanted to share what I have just in case it might prove useful to someone. Use or throw
away at your leisure...
Bill
Index: file_io/unix/pipe.c
===================================================================
RCS file: /home/cvs/apr/file_io/unix/pipe.c,v
retrieving revision 1.46
diff -u -r1.46 pipe.c
--- file_io/unix/pipe.c 2001/02/16 04:15:37 1.46
+++ file_io/unix/pipe.c 2001/06/20 18:31:01
@@ -193,17 +193,20 @@
apr_pool_cleanup_null);
return APR_SUCCESS;
}
-
-apr_status_t apr_file_namedpipe_create(const char *filename,
- apr_fileperms_t perm, apr_pool_t *cont)
+APR_DECLARE(apr_status_t) apr_file_namedpipe_create(apr_file_t **pipe,
+ const char *pipename,
+ apr_fileperms_t perm,
+ apr_pool_t *p)
{
mode_t mode = apr_unix_perms2mode(perm);
if (mkfifo(filename, mode) == -1) {
return errno;
}
- return APR_SUCCESS;
-}
+
+ return apr_file_open(pipe, pipename, flag, perm, p);
+}
+
Index: file_io/win32/open.c
===================================================================
RCS file: /home/cvs/apr/file_io/win32/open.c,v
retrieving revision 1.76
diff -u -r1.76 open.c
--- file_io/win32/open.c 2001/06/07 14:32:21 1.76
+++ file_io/win32/open.c 2001/06/20 18:31:01
@@ -169,7 +169,7 @@
return flush_rv;
}
-APR_DECLARE(apr_status_t) apr_file_open(apr_file_t **new, const char *fname,
+APR_DECLARE(apr_status_t) apr_file_open(apr_file_t **new, const char *name,
apr_int32_t flag, apr_fileperms_t perm,
apr_pool_t *cont)
{
@@ -177,6 +177,7 @@
* sdbm and any other random files! We _must_ rethink
* this approach.
*/
+ char *fname;
HANDLE handle = INVALID_HANDLE_VALUE;
DWORD oflags = 0;
DWORD createflags = 0;
@@ -185,6 +186,13 @@
apr_oslevel_e os_level;
apr_status_t rv;
+ if (flag & APR_PIPE_OPEN) {
+ fname = apr_psprintf(cont, "\\\\.\\pipe\\%s", name);
+ }
+ else {
+ fname = name;
+ }
+
if (flag & APR_READ) {
oflags |= GENERIC_READ;
}
@@ -293,8 +301,14 @@
(*new)->pOverlapped = (OVERLAPPED*) apr_pcalloc(cont, sizeof(OVERLAPPED));
(*new)->pOverlapped->hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
}
+
+ if (flag & APR_PIPE_OPEN) {
+ (*new)->pipe = 1;
+ }
+ else {
+ (*new)->pipe = 0;
+ }
- (*new)->pipe = 0;
(*new)->timeout = -1;
(*new)->ungetchar = -1;
(*new)->eof_hit = 0;
Index: file_io/win32/pipe.c
===================================================================
RCS file: /home/cvs/apr/file_io/win32/pipe.c,v
retrieving revision 1.37
diff -u -r1.37 pipe.c
--- file_io/win32/pipe.c 2001/06/06 16:04:54 1.37
+++ file_io/win32/pipe.c 2001/06/20 18:31:01
@@ -232,3 +232,34 @@
return APR_SUCCESS;
}
+
+APR_DECLARE(apr_status_t) apr_file_namedpipe_create(apr_file_t **pipe,
+ const char *pipename,
+ apr_fileperms_t perm,
+ apr_pool_t *p)
+{
+ SECURITY_ATTRIBUTES sa;
+
+ (*pipe) = (apr_file_t *)apr_pcalloc(p, sizeof(apr_file_t));
+ (*pipe)->cntxt = p;
+ (*pipe)->fname = apr_psprintf(p, "\\\\.\\pipe\\%s", pipename);
+ (*pipe)->pipe = 1;
+
+ sa.nLength = sizeof(sa);
+ sa.bInheritHandle = TRUE;
+ sa.lpSecurityDescriptor = NULL;
+
+ (*pipe)->filehand = CreateNamedPipe((*pipe)->fname,
+ PIPE_ACCESS_DUPLEX,
+ PIPE_TYPE_BYTE, file://dwPipeMode,
+ 1, file://nMaxInstances,
+ 8182, file://nOutBufferSize,
+ 8192, file://nInBufferSize,
+ 1, file://nDefaultTimeOut,
+ &sa);
+
+ if ((*pipe)->filehand == INVALID_HANDLE_VALUE)
+ return apr_get_os_error();
+
+ return APR_SUCCESS;
+}
Index: include/apr_file_io.h
===================================================================
RCS file: /home/cvs/apr/include/apr_file_io.h,v
retrieving revision 1.102
diff -u -r1.102 apr_file_io.h
--- include/apr_file_io.h 2001/05/31 00:11:12 1.102
+++ include/apr_file_io.h 2001/06/20 18:31:02
@@ -89,6 +89,7 @@
#define APR_SHARELOCK 1024 /* Platform dependent support for higher
level locked read/write access to support
writes across process/machines */
+#define APR_PIPE_OPEN 2048
/* flags for apr_file_seek */
#define APR_SET SEEK_SET
@@ -410,9 +411,10 @@
* @param cont The pool to operate on.
* @deffunc apr_status_t apr_file_namedpipe_create(const char *filename, apr_fileperms_t
perm, apr_pool_t *cont)
*/
-APR_DECLARE(apr_status_t) apr_file_namedpipe_create(const char *filename,
- apr_fileperms_t perm,
- apr_pool_t *cont);
+APR_DECLARE(apr_status_t) apr_file_namedpipe_create(apr_file_t **in,
+ const char *filename,
+ apr_fileperms_t perm,
+ apr_pool_t *cont);
/**
* Get the timeout value for a pipe or manipulate the blocking state.
Re: [PATCH] Some named pipe hacking...
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Sun, Jun 24, 2001 at 10:30:00AM -0700, Justin Erenkrantz wrote:
> On Sun, Jun 24, 2001 at 07:18:41PM +0200, Luke Kenneth Casson Leighton wrote:
> > > 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?
>
> Yeah, that would be sufficient (Unix only). Just give us an idea of
> what you are talking about. The fact that on NT/OS2 it goes directly
> to a system call that is named pipes and on Unix goes to domain sockets
> (I need to read up on those) doesn't bother me in the least. The
> functionality would have to be equivalent (LCD) and they would have to
> be able to talk to each other.
i have a question: can you do a select() / listen() / bind() / accept()
on a *unix* namedpipe?
can you do equivalent-of-select() /listen() ... on an NTnamedpipe?
> So the Unix implementation on the network side has to be compatible
> with the NT implementation - how are endian issues dealt with in SMB,
> for example?
well, in samba, there are conversion-macros - equivalent to
ntoh - but intel-byte-order not network-order :)
so, you always end up, in your host, with data in the right
order.
but, i have to point out: it doesn't really have anything
to do with creating an NTpipe api :) :) okay, maybe it does,
and i'm so used to it, i forget :)
> > 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.
>
> That's what we are here for. =) We're not perfect, but enough good
> people looking at it will do just fine for our purposes. -- justin
:)
Re: [PATCH] Some named pipe hacking...
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sun, Jun 24, 2001 at 07:18:41PM +0200, Luke Kenneth Casson Leighton wrote:
> > 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?
Yeah, that would be sufficient (Unix only). Just give us an idea of
what you are talking about. The fact that on NT/OS2 it goes directly
to a system call that is named pipes and on Unix goes to domain sockets
(I need to read up on those) doesn't bother me in the least. The
functionality would have to be equivalent (LCD) and they would have to
be able to talk to each other.
So the Unix implementation on the network side has to be compatible
with the NT implementation - how are endian issues dealt with in SMB,
for example?
> 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.
That's what we are here for. =) We're not perfect, but enough good
people looking at it will do just fine for our purposes. -- justin
Re: [PATCH] Some named pipe hacking...
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
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.
okay.
okay.
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
xvl/
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 :)
luke
Re: [PATCH] Some named pipe hacking...
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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.
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.
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
can't use code derived from Samba unless *you* are the copyright
holder), 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.
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
Re: [PATCH] Some named pipe hacking...
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> While I agree with 99% of what Roy said, I would like to make one
> clarification from my point of view. I don't really care if it conflicts
> with a name on Unix. I do however care if the name conflicts with
> something in POSIX or something in common use on multiple platforms. If
> we implement something that conflicts with a name on Windows, and our
> implementation doesn't look incredibly similar to that entity on Windows,
> then I consider that a problem.
ack. it _is_ the NT api i'm after. the whole lot, but
at this time, just the NTNamedPipes ones.
really, i _really_ think tht that apr nt version should just
be v.clearly a shim directly to TransactNamedPipe and CreateNamedPipe,
and then the horrors - that _don't_ involve unix namedpipe AT ALL
but unix domain sockets instead - go on to emulate that under
unix, with APR_NOTIMPL returned for bits decided _not_ to
be implemented right now. and specifically, right now, that
means, in my book, if the name contains a remote server on
unix, you return APR_NOTIMPL.
what you think?
lukes
Re: [PATCH] Some named pipe hacking...
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
hiya,
didn't get a response back regarding the namedpipes / ntpipes
issues, still have some questions outstanding, perhaps someone
can help me understand?
i asked earlier about whether it is possible to do a select()
on a [unix] namedpipe: i have since discovered apr_poll()
so the question should be:
in the proposed [generic, unix-named-pipe-like, not the
nt-named-pipe-like one!] apr_namedpipe() api:
will it be possible to do an apr_poll(), fork or thread,
deal with the request or requests?
this is really important for the viability and useability
of any proposed apr_namedpipe() implementation.
as an aside, in case you're wondering, one of the reasons
i haven't posted Code for an apr_ntpipe() implementation
is because the infrastructure to support it / code it
easily doesn't exist. namely, what i think will be needed
is probably likely to be close to the apr_IOL (took me
a while to work out that means input / output layer :)
where can more info about the IOL be found? i have
a sneaky suspicion that any namedpipe implementation -
both the proposed apr_namedpipe() _and_ the proposed
apr_ntpipe() APIs will need to be 'plugged in' behind
an IOL, because otherwise, adding them in behind
the existing code will make a horrible mess of
exceptions etc. and will result in a botch-job-of-an-IOL
_anyway_ :) :)
all best,
luke
Re: [PATCH] Some named pipe hacking...
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Mon, Jun 25, 2001 at 12:54:26PM -0500, William A. Rowe, Jr. wrote:
> From: "Luke Kenneth Casson Leighton" <lk...@samba-tng.org>
> > 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?
>
> Because APR MUST BE USEFUL ON ALL SUPPORTED PLATFORMS.
acknowledged and already understood.
btw, been thinking a lot but too busy
to write it up: 200 o/s msgs and only 30mins/day to
clear them.
a) the NAL would go a long way to fulfilling that bold statement
and also providing the functionality i will need.
b) i have to say, after a lot of thought, that for xvl
(but not for a dce/rpc and smb client/server implementation)
the apr_namedpipe_xxx() api - as posted - *as long as
it's possible to do a select / listen / accept on all
platforms* - will be enough.
> > ...tell you what, i will write up an API proposal and
> > morph some code to an apr api. less talk, more code :)
>
> That would help the discussion and simply call them remote pipes.
i thought maybe ntpipes? remotepipe is just as good.
all best,
luke
Re: [PATCH] Some named pipe hacking...
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: "Luke Kenneth Casson Leighton" <lk...@samba-tng.org>
Sent: Sunday, June 24, 2001 12:05 PM
> 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?
Because APR MUST BE USEFUL ON ALL SUPPORTED PLATFORMS.
> ...tell you what, i will write up an API proposal and
> morph some code to an apr api. less talk, more code :)
That would help the discussion and simply call them remote pipes.
> so, your point is noted, and my question is, is it enough to
> stop apr from doing it [NT-style namedpipes]?
Unless it will be provided to other users, at least through Samba
or some other means that users _may_ configure if they like, then
yes, this stops apr from doing it.
Bill
Re: [PATCH] Some named pipe hacking...
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
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
Re: [PATCH] Some named pipe hacking...
Posted by rb...@covalent.net.
> > 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.
> 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.
While I agree with 99% of what Roy said, I would like to make one
clarification from my point of view. I don't really care if it conflicts
with a name on Unix. I do however care if the name conflicts with
something in POSIX or something in common use on multiple platforms. If
we implement something that conflicts with a name on Windows, and our
implementation doesn't look incredibly similar to that entity on Windows,
then I consider that a problem.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] Some named pipe hacking...
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> 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.
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.
> 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.
....Roy
Re: [PATCH] Some named pipe hacking...
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Thu, Jun 21, 2001 at 10:53:57AM -0500, William A. Rowe, Jr. wrote:
> From: "Luke Kenneth Casson Leighton" <lk...@samba-tng.org>
> Sent: Thursday, June 21, 2001 7:35 AM
>
>
> > thanks bill!
> >
> > recommendation. use the actual expected format for pipename:
> > pass in "\\.\\PIPE\pipename" _not_ "pipename" and have it
> > hidden / constructed by apr.
>
> APR is here to make folks cross-plaform development blindingly simple.
> And (for the most part) it does. What you've proposed makes things far
> more difficult to follow. Named unix pipes are local, no?
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.
> So the _Lowest
> Common Denominator_ says that our APR namedpipe implementation is to create
> local pipes.
only if youconsider unix named pipes to be the same as nt named
pipes, which they certainly aren't.
okay.
i have a question. is it unreasonable to expect Unix developers
to learn an API that is identical in functionality to an NT
(and an OS/2) one?
think through what you are proposing.
i want to implement NT named pipes, using or _in_ APR.
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.
and then, you expect me to implement 'remote' named pipes
as a shim on top of a crippled, perfectly good remote
named pipes implementation? [but not in apr, because it's
considered too complex]
*blink* uhn? :) :)
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.
> If you want to create a cross-machine pipe architecture, then you must add
> another function with char *machine, char *pipename semantics. If you have
> at least a rough outline of the implementation for this on unix.
rough? better than that, i have working code. it's in use in
samba tng today, has been for about a year and a half.
it duplicates the functionality of NT named pipes.
i was hoping to use apr to make a better version of the code
in tng, having learned from the first impl.
> One problem with using Netbios in any public environment is that the vast
> majority of operators will clamp down on the Netbios ports of any public
> machine outside the firewall. This is for pretty good reasons, given the
> paucity of security on that interface.
yes. there are a couple of other similar situations where
proposals - or actual implementations - have provided proxying
of other transports onto other transports [explanation: NetBIOS
is actually a full transport, but no-one implements it on
its own, now, only the proxied versions]
one is DCE/RPC over HTTP [this was added to NT for exchange's
benefit: it runs on port 689 and there is an IIS component
that is enabled BY DEFAULT ON NT5 argh argh that proxies this
to port 80]. so, now all of your entire NT domain infrastructure,
including exchange etc, is vulnerable to dce/rpc-related
security attacks because ms wanted their customers to be
able to read email through a firewall. greaaat.
the other is the new TCP over HTTP proposal (a draft rfc i
understand).
but anyway. so... yes? and? yes, i agree with you. i'd
even recommend it. the ports are 137, 138 and 139. if you
want to shut down SMB over TCP too, that's on port 445.
and if you want to shut down dce/rpc portmapper, that's
on 135. and the dce/rpc over http? port 689, and then
disable the redirector component too, in IIS.
... but despite all this, i don't see it as a relevant point
to make as a reason not to fully implement NT named pipes.
> If you are looking for a cross-machine semantic,
yes.
> the underlying support must also be cross-platform.
yes. now i know _you_ know that.
> If you propose Samba for this,
[no i don't: see below]
> then fine, let's start discussing that.
[great!]
... what i actually want to propose is a project that
sander and i have been considering: an alternative implementation
to samba.
there _aren't_ any open source alternatives to samba,
and sander and i would both like to implement one - as
an Apache Software Foundation project.
now, given microsoft's recent announcement regarding
their SDK - You May Not Implement Or Use This In
Open Source Projects Except BSD Ones, that looks like
being an increasingly attractive option.
anway. i apologise in advance for holding most of the
designs for an approximately... 2 million lines of code
project [series] in my head. i get a bit confused
occasionally about which bits i've actually explained to people.
people ask for justifications, but they're like... six months
down the line, and i've already planned _now_ for _then_.
so yes, a full cross-machine, cross-platform NT-like
named pipe implementation _is_ important - no, it's
absolutely critical - to the plans and designs that
i wish to achieve.
and the whole reason that i am not speaking to those idiots
who now consider themselves responsible for samba's
development is because they couldn't 'get' this simple
concept [an NT-like named pipe implementation], but wanted to
keep samba as one, big monolithic program.
170 THOUSAND lines of code - one program - and *only
getting bigger!*. by the time they are done, which at
the rate they're going will be when NT is retired,
that will probably be about 400 to 500 thousand lines.
utterly, utterly mad.
> If this implementation is strictly for NT, please don't bloat code with things
> you can do trivialy and faster with the native API.
regarding xvl, which i am also wanting to use APR for;
the code i have is specifically restricted to unix (xvl) _because_
there is no appropriate inter-process client/server code available
for me to use in apr.
for me, xvl is a really cool little project that helps keep
me going, and also is a good 'test' case [only 16,000 LOC].
i think i will actually go out and get very very drunk when
xvl compiles and works in apache on NT :) and i think
the php people would be very happy too: currently, php
on NT can *only* be run as a cgi-bin stand-alone exe,
which is a bit mad. an NT namedpipe API in apr would
go a long, ong way to making php on NT more efficient.
all best,
luke
Re: [PATCH] Some named pipe hacking...
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: "Luke Kenneth Casson Leighton" <lk...@samba-tng.org>
Sent: Thursday, June 21, 2001 7:35 AM
> thanks bill!
>
> recommendation. use the actual expected format for pipename:
> pass in "\\.\\PIPE\pipename" _not_ "pipename" and have it
> hidden / constructed by apr.
APR is here to make folks cross-plaform development blindingly simple.
And (for the most part) it does. What you've proposed makes things far
more difficult to follow. Named unix pipes are local, no? So the _Lowest
Common Denominator_ says that our APR namedpipe implementation is to create
local pipes.
If you want to create a cross-machine pipe architecture, then you must add
another function with char *machine, char *pipename semantics. If you have
at least a rough outline of the implementation for this on unix.
One problem with using Netbios in any public environment is that the vast
majority of operators will clamp down on the Netbios ports of any public
machine outside the firewall. This is for pretty good reasons, given the
paucity of security on that interface.
If you are looking for a cross-machine semantic, the underlying support must
also be cross-platform. If you propose Samba for this, then fine, let's start
discussing that.
If this implementation is strictly for NT, please don't bloat code with things
you can do trivialy and faster with the native API.
Bill
Re: [PATCH] Some named pipe hacking...
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> 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.
Re: [PATCH] Some named pipe hacking...
Posted by Aaron Bannert <aa...@ebuilt.com>.
On Thu, Jun 21, 2001 at 05:43:41PM +0200, Luke Kenneth Casson Leighton wrote:
> On Thu, Jun 21, 2001 at 07:44:25AM -0700, Justin Erenkrantz wrote:
> > On Thu, Jun 21, 2001 at 02:35:19PM +0200, Luke Kenneth Casson Leighton wrote:
> > > thanks bill!
> > >
> > > recommendation. use the actual expected format for pipename:
> > > pass in "\\.\\PIPE\pipename" _not_ "pipename" and have it
> > > hidden / constructed by apr.
> >
> > Can you please give a concrete example why you need this?
>
> we would like to rewrite TNG's services using APR.
>
> that includes, but is not limited to:
>
> a NetBIOS redirector, running on ports 137, 138, 139 and 445
>
> a NetBIOS Name Server (WINS), running on top of the NetBIOS redirector.
>
> a Network Neighbourhood server, ditto.
>
> an SMB server, ditto.
>
> a LANMAN server, running on top of the SMB IPC$ server,
> which is actually with an interface of \\.\PIPE\LANMAN
> [which is why i am advocating pipes]
>
> a SAMR server, same thing, running DCE/RPC over \\.\PIPE\samr
>
> an lsarpc server, same thing
>
> a NETLOGON server
>
> a svcctl server
>
> a srvsvc server
>
> all of the dce/rpc services are currently bounced out via
> a unix-domain-socket, and i would like to use an APR
> framework for the portability of this project.
>
> the NetBIOS and SMB ones are currently 'taking over' ports
> 137, 138, 139 and 445, however there are people out there
> who would like to make a NAL out of this stuff so that
> others can 'join in the fun'.
>
>
> > I don't think any of us are seeing why you need to use the Win32 naming
> > conventions for a pipe. What you are suggesting goes against all of the
> > precedents in APR. -- justin
>
> whoops :) like i said, i am aware that the 'traditional' focus of
> APR has been to emulate unix and make it portable that way.
>
> lukes
Hi Luke,
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.
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'm off my rocker here, let me know. I can't say I'm that familiar
with the APR code *yet* :)
-aaron
Re: [PATCH] Some named pipe hacking...
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Thu, Jun 21, 2001 at 07:44:25AM -0700, Justin Erenkrantz wrote:
> On Thu, Jun 21, 2001 at 02:35:19PM +0200, Luke Kenneth Casson Leighton wrote:
> > thanks bill!
> >
> > recommendation. use the actual expected format for pipename:
> > pass in "\\.\\PIPE\pipename" _not_ "pipename" and have it
> > hidden / constructed by apr.
>
> Can you please give a concrete example why you need this?
we would like to rewrite TNG's services using APR.
that includes, but is not limited to:
a NetBIOS redirector, running on ports 137, 138, 139 and 445
a NetBIOS Name Server (WINS), running on top of the NetBIOS redirector.
a Network Neighbourhood server, ditto.
an SMB server, ditto.
a LANMAN server, running on top of the SMB IPC$ server,
which is actually with an interface of \\.\PIPE\LANMAN
[which is why i am advocating pipes]
a SAMR server, same thing, running DCE/RPC over \\.\PIPE\samr
an lsarpc server, same thing
a NETLOGON server
a svcctl server
a srvsvc server
all of the dce/rpc services are currently bounced out via
a unix-domain-socket, and i would like to use an APR
framework for the portability of this project.
the NetBIOS and SMB ones are currently 'taking over' ports
137, 138, 139 and 445, however there are people out there
who would like to make a NAL out of this stuff so that
others can 'join in the fun'.
> I don't think any of us are seeing why you need to use the Win32 naming
> conventions for a pipe. What you are suggesting goes against all of the
> precedents in APR. -- justin
whoops :) like i said, i am aware that the 'traditional' focus of
APR has been to emulate unix and make it portable that way.
lukes
Re: [PATCH] Some named pipe hacking...
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Jun 21, 2001 at 02:35:19PM +0200, Luke Kenneth Casson Leighton wrote:
> thanks bill!
>
> recommendation. use the actual expected format for pipename:
> pass in "\\.\\PIPE\pipename" _not_ "pipename" and have it
> hidden / constructed by apr.
Can you please give a concrete example why you need this?
I don't think any of us are seeing why you need to use the Win32 naming
conventions for a pipe. What you are suggesting goes against all of the
precedents in APR. -- justin
Re: [PATCH] Some named pipe hacking...
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
thanks bill!
recommendation. use the actual expected format for pipename:
pass in "\\.\\PIPE\pipename" _not_ "pipename" and have it
hidden / constructed by apr.
apr should _check_ that it is of a valid format:
\\.*\\[PIPE|pipe]\\.*
but i think it really _should_ be directly exposed.
to be useful, to me, the unix implementation should actually
be a unix domain socket. pipename i suggest be 'redirected'
to /tmp/.apr/pipename.
yes, i know, that will create
/tmp/.apr/\\.\\PIPE\\pipename
and this isn't as big a deal as you might expect.
luke
On Wed, Jun 20, 2001 at 04:22:54PM -0400, Bill Stoddard wrote:
> This is NOT ready to be committed and in fact it may be a complete waste of time. I had a
> few minutes to hack around a couple of days back and came up with this. I did not even
> attempt to compile the unix implementation of ap_file_namedpipe_create() much less run it.
> The Windows implementation of ap_file_namedpipe_create() seems to work
>
> I am posting this because I will unlikely have time to work on this for quite a while and
> wanted to share what I have just in case it might prove useful to someone. Use or throw
> away at your leisure...
>
> Bill
>
> Index: file_io/unix/pipe.c
> ===================================================================
> RCS file: /home/cvs/apr/file_io/unix/pipe.c,v
> retrieving revision 1.46
> diff -u -r1.46 pipe.c
> --- file_io/unix/pipe.c 2001/02/16 04:15:37 1.46
> +++ file_io/unix/pipe.c 2001/06/20 18:31:01
> @@ -193,17 +193,20 @@
> apr_pool_cleanup_null);
> return APR_SUCCESS;
> }
> -
> -apr_status_t apr_file_namedpipe_create(const char *filename,
> - apr_fileperms_t perm, apr_pool_t *cont)
> +APR_DECLARE(apr_status_t) apr_file_namedpipe_create(apr_file_t **pipe,
> + const char *pipename,
> + apr_fileperms_t perm,
> + apr_pool_t *p)
> {
> mode_t mode = apr_unix_perms2mode(perm);
>
> if (mkfifo(filename, mode) == -1) {
> return errno;
> }
> - return APR_SUCCESS;
> -}
> +
> + return apr_file_open(pipe, pipename, flag, perm, p);
> +}
> +
>
>
>
> Index: file_io/win32/open.c
> ===================================================================
> RCS file: /home/cvs/apr/file_io/win32/open.c,v
> retrieving revision 1.76
> diff -u -r1.76 open.c
> --- file_io/win32/open.c 2001/06/07 14:32:21 1.76
> +++ file_io/win32/open.c 2001/06/20 18:31:01
> @@ -169,7 +169,7 @@
> return flush_rv;
> }
>
> -APR_DECLARE(apr_status_t) apr_file_open(apr_file_t **new, const char *fname,
> +APR_DECLARE(apr_status_t) apr_file_open(apr_file_t **new, const char *name,
> apr_int32_t flag, apr_fileperms_t perm,
> apr_pool_t *cont)
> {
> @@ -177,6 +177,7 @@
> * sdbm and any other random files! We _must_ rethink
> * this approach.
> */
> + char *fname;
> HANDLE handle = INVALID_HANDLE_VALUE;
> DWORD oflags = 0;
> DWORD createflags = 0;
> @@ -185,6 +186,13 @@
> apr_oslevel_e os_level;
> apr_status_t rv;
>
> + if (flag & APR_PIPE_OPEN) {
> + fname = apr_psprintf(cont, "\\\\.\\pipe\\%s", name);
> + }
> + else {
> + fname = name;
> + }
> +
> if (flag & APR_READ) {
> oflags |= GENERIC_READ;
> }
> @@ -293,8 +301,14 @@
> (*new)->pOverlapped = (OVERLAPPED*) apr_pcalloc(cont, sizeof(OVERLAPPED));
> (*new)->pOverlapped->hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
> }
> +
> + if (flag & APR_PIPE_OPEN) {
> + (*new)->pipe = 1;
> + }
> + else {
> + (*new)->pipe = 0;
> + }
>
> - (*new)->pipe = 0;
> (*new)->timeout = -1;
> (*new)->ungetchar = -1;
> (*new)->eof_hit = 0;
> Index: file_io/win32/pipe.c
> ===================================================================
> RCS file: /home/cvs/apr/file_io/win32/pipe.c,v
> retrieving revision 1.37
> diff -u -r1.37 pipe.c
> --- file_io/win32/pipe.c 2001/06/06 16:04:54 1.37
> +++ file_io/win32/pipe.c 2001/06/20 18:31:01
> @@ -232,3 +232,34 @@
>
> return APR_SUCCESS;
> }
> +
> +APR_DECLARE(apr_status_t) apr_file_namedpipe_create(apr_file_t **pipe,
> + const char *pipename,
> + apr_fileperms_t perm,
> + apr_pool_t *p)
> +{
> + SECURITY_ATTRIBUTES sa;
> +
> + (*pipe) = (apr_file_t *)apr_pcalloc(p, sizeof(apr_file_t));
> + (*pipe)->cntxt = p;
> + (*pipe)->fname = apr_psprintf(p, "\\\\.\\pipe\\%s", pipename);
> + (*pipe)->pipe = 1;
> +
> + sa.nLength = sizeof(sa);
> + sa.bInheritHandle = TRUE;
> + sa.lpSecurityDescriptor = NULL;
> +
> + (*pipe)->filehand = CreateNamedPipe((*pipe)->fname,
> + PIPE_ACCESS_DUPLEX,
> + PIPE_TYPE_BYTE, file://dwPipeMode,
> + 1, file://nMaxInstances,
> + 8182, file://nOutBufferSize,
> + 8192, file://nInBufferSize,
> + 1, file://nDefaultTimeOut,
> + &sa);
> +
> + if ((*pipe)->filehand == INVALID_HANDLE_VALUE)
> + return apr_get_os_error();
> +
> + return APR_SUCCESS;
> +}
> Index: include/apr_file_io.h
> ===================================================================
> RCS file: /home/cvs/apr/include/apr_file_io.h,v
> retrieving revision 1.102
> diff -u -r1.102 apr_file_io.h
> --- include/apr_file_io.h 2001/05/31 00:11:12 1.102
> +++ include/apr_file_io.h 2001/06/20 18:31:02
> @@ -89,6 +89,7 @@
> #define APR_SHARELOCK 1024 /* Platform dependent support for higher
> level locked read/write access to support
> writes across process/machines */
> +#define APR_PIPE_OPEN 2048
>
> /* flags for apr_file_seek */
> #define APR_SET SEEK_SET
> @@ -410,9 +411,10 @@
> * @param cont The pool to operate on.
> * @deffunc apr_status_t apr_file_namedpipe_create(const char *filename, apr_fileperms_t
> perm, apr_pool_t *cont)
> */
> -APR_DECLARE(apr_status_t) apr_file_namedpipe_create(const char *filename,
> - apr_fileperms_t perm,
> - apr_pool_t *cont);
> +APR_DECLARE(apr_status_t) apr_file_namedpipe_create(apr_file_t **in,
> + const char *filename,
> + apr_fileperms_t perm,
> + apr_pool_t *cont);
>
> /**
> * Get the timeout value for a pipe or manipulate the blocking state.
>