github
/
putty
зеркало из https://github.com/github/putty.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
putty/windows/winnps.c

260 строки
7.1 KiB
C
Исходник Обычный вид История

Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
/*
* Windows support module which deals with being a named-pipe server.
*/
#include <stdio.h>
#include <assert.h>
#define DEFINE_PLUG_METHOD_MACROS
#include "tree234.h"
#include "putty.h"
#include "network.h"
#include "proxy.h"
#include "ssh.h"
#if !defined NO_SECURITY
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 18:05:41 +04:00
#include "winsecur.h"
Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 14:50:37 +03:00
Socket make_handle_socket(HANDLE send_H, HANDLE recv_H, HANDLE stderr_H,
Plug plug, int overlapped);
Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
typedef struct Socket_named_pipe_server_tag *Named_Pipe_Server_Socket;
struct Socket_named_pipe_server_tag {
const struct socket_function_table *fn;
/* the above variable absolutely *must* be the first in this structure */
/* Parameters for (repeated) creation of named pipe objects */
PSECURITY_DESCRIPTOR psd;
PACL acl;
char *pipename;
/* The current named pipe object + attempt to connect to it */
HANDLE pipehandle;
OVERLAPPED connect_ovl;
Clean up a stale foreign handle in winnps.c. I had set up an event object for signalling incoming connections to the named pipe, and then called handle_add_foreign_event to get that event object watched for connections - but when I closed down the listening pipe, I deleted the event object without also cancelling that foreign-event handle, so that winhandl.c would potentially call the callback for a destroyed object.
2015-04-07 23:54:41 +03:00
struct handle *callback_handle; /* winhandl.c's reference */
Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
/* PuTTY Socket machinery */
Plug plug;
char *error;
};
static Plug sk_namedpipeserver_plug(Socket s, Plug p)
{
Named_Pipe_Server_Socket ps = (Named_Pipe_Server_Socket) s;
Plug ret = ps->plug;
if (p)
ps->plug = p;
return ret;
}
static void sk_namedpipeserver_close(Socket s)
{
Named_Pipe_Server_Socket ps = (Named_Pipe_Server_Socket) s;
Clean up a stale foreign handle in winnps.c. I had set up an event object for signalling incoming connections to the named pipe, and then called handle_add_foreign_event to get that event object watched for connections - but when I closed down the listening pipe, I deleted the event object without also cancelling that foreign-event handle, so that winhandl.c would potentially call the callback for a destroyed object.
2015-04-07 23:54:41 +03:00
if (ps->callback_handle)
handle_free(ps->callback_handle);
Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
CloseHandle(ps->pipehandle);
CloseHandle(ps->connect_ovl.hEvent);
sfree(ps->error);
sfree(ps->pipename);
if (ps->acl)
LocalFree(ps->acl);
if (ps->psd)
LocalFree(ps->psd);
sfree(ps);
}
static const char *sk_namedpipeserver_socket_error(Socket s)
{
Named_Pipe_Server_Socket ps = (Named_Pipe_Server_Socket) s;
return ps->error;
}
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 15:57:45 +03:00
static char *sk_namedpipeserver_peer_info(Socket s)
{
return NULL;
}
Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
static int create_named_pipe(Named_Pipe_Server_Socket ps, int first_instance)
{
SECURITY_ATTRIBUTES sa;
memset(&sa, 0, sizeof(sa));
sa.nLength = sizeof(sa);
sa.lpSecurityDescriptor = ps->psd;
sa.bInheritHandle = FALSE;
ps->pipehandle = CreateNamedPipe
(/* lpName */
ps->pipename,
/* dwOpenMode */
PIPE_ACCESS_DUPLEX |
FILE_FLAG_OVERLAPPED |
(first_instance ? FILE_FLAG_FIRST_PIPE_INSTANCE : 0),
/* dwPipeMode */
PIPE_TYPE_BYTE | PIPE_READMODE_BYTE | PIPE_WAIT
#ifdef PIPE_REJECT_REMOTE_CLIENTS
| PIPE_REJECT_REMOTE_CLIENTS
#endif
,
/* nMaxInstances */
PIPE_UNLIMITED_INSTANCES,
/* nOutBufferSize, nInBufferSize */
4096, 4096, /* FIXME: think harder about buffer sizes? */
/* nDefaultTimeOut */
0 /* default timeout */,
/* lpSecurityAttributes */
&sa);
return ps->pipehandle != INVALID_HANDLE_VALUE;
}
static Socket named_pipe_accept(accept_ctx_t ctx, Plug plug)
{
HANDLE conn = (HANDLE)ctx.p;
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 14:50:37 +03:00
return make_handle_socket(conn, conn, NULL, plug, TRUE);
Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
}
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 18:05:41 +04:00
/*
* Dummy SockAddr type which just holds a named pipe address. Only
* used for calling plug_log from named_pipe_accept_loop() here.
*/
SockAddr sk_namedpipe_addr(const char *pipename);
Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
static void named_pipe_accept_loop(Named_Pipe_Server_Socket ps,
int got_one_already)
{
while (1) {
int error;
char *errmsg;
if (got_one_already) {
/* If we were called with a connection already waiting,
* skip this step. */
got_one_already = FALSE;
error = 0;
} else {
/*
* Call ConnectNamedPipe, which might succeed or might
* tell us that an overlapped operation is in progress and
* we should wait for our event object.
*/
if (ConnectNamedPipe(ps->pipehandle, &ps->connect_ovl))
error = 0;
else
error = GetLastError();
if (error == ERROR_IO_PENDING)
return;
}
if (error == 0 || error == ERROR_PIPE_CONNECTED) {
/*
* We've successfully retrieved an incoming connection, so
* ps->pipehandle now refers to that connection. So
* convert that handle into a separate connection-type
* Socket, and create a fresh one to be the new listening
* pipe.
*/
HANDLE conn = ps->pipehandle;
accept_ctx_t actx;
actx.p = (void *)conn;
if (plug_accepting(ps->plug, named_pipe_accept, actx)) {
/*
* If the plug didn't want the connection, might as
* well close this handle.
*/
CloseHandle(conn);
}
if (!create_named_pipe(ps, FALSE)) {
error = GetLastError();
} else {
/*
* Go round again to see if more connections can be
* got, or to begin waiting on the event object.
*/
continue;
}
}
errmsg = dupprintf("Error while listening to named pipe: %s",
win_strerror(error));
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 18:05:41 +04:00
plug_log(ps->plug, 1, sk_namedpipe_addr(ps->pipename), 0,
Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
errmsg, error);
sfree(errmsg);
break;
}
}
static void named_pipe_connect_callback(void *vps)
{
Named_Pipe_Server_Socket ps = (Named_Pipe_Server_Socket)vps;
named_pipe_accept_loop(ps, TRUE);
}
Socket new_named_pipe_listener(const char *pipename, Plug plug)
{
/*
* This socket type is only used for listening, so it should never
* be asked to write or flush or set_frozen.
*/
static const struct socket_function_table socket_fn_table = {
sk_namedpipeserver_plug,
sk_namedpipeserver_close,
NULL /* write */,
NULL /* write_oob */,
NULL /* write_eof */,
NULL /* flush */,
NULL /* set_frozen */,
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 15:57:45 +03:00
sk_namedpipeserver_socket_error,
sk_namedpipeserver_peer_info,
Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
};
Named_Pipe_Server_Socket ret;
ret = snew(struct Socket_named_pipe_server_tag);
ret->fn = &socket_fn_table;
ret->plug = plug;
ret->error = NULL;
ret->psd = NULL;
ret->pipename = dupstr(pipename);
ret->acl = NULL;
Clean up a stale foreign handle in winnps.c. I had set up an event object for signalling incoming connections to the named pipe, and then called handle_add_foreign_event to get that event object watched for connections - but when I closed down the listening pipe, I deleted the event object without also cancelling that foreign-event handle, so that winhandl.c would potentially call the callback for a destroyed object.
2015-04-07 23:54:41 +03:00
ret->callback_handle = NULL;
Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
assert(strncmp(pipename, "\\\\.\\pipe\\", 9) == 0);
assert(strchr(pipename + 9, '\\') == NULL);
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 18:05:41 +04:00
if (!make_private_security_descriptor(GENERIC_READ | GENERIC_WRITE,
Switch to using SIDs in make_private_security_descriptor(). Daniel Meidlinger reports that at least one Windows machine which is not obviously otherwise misconfigured will respond to our SetEntriesInAcl call with odd errors like ERROR_NONE_MAPPED or ERROR_TRUSTED_RELATIONSHIP_FAILURE. This is apparently to do with failure to convert the names "EVERYONE" and "CURRENT_USER" used in the ACL specification to SIDs. (Or perhaps only one of them is the problem - I didn't investigate in that direction.) If we instead construct a fully SID-based ACL, using the well-known world SID in place of EVERYONE and calling our existing get_user_sid routine in place of CURRENT_USER, he reports that the problem goes away, so let's do that instead. While I'm here, I've slightly simplified the function prototype of make_private_security_descriptor(), by turning 'networksid' into an internal static that we can reuse in subsequent calls once we've set it up. (Mostly because I didn't fancy adding another two pointless parameters at every call site for the two new SIDs.) [originally from svn r10096]
2013-11-25 22:35:14 +04:00
&ret->psd, &ret->acl, &ret->error)) {
Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
goto cleanup;
}
if (!create_named_pipe(ret, TRUE)) {
ret->error = dupprintf("unable to create named pipe '%s': %s",
pipename, win_strerror(GetLastError()));
goto cleanup;
}
memset(&ret->connect_ovl, 0, sizeof(ret->connect_ovl));
ret->connect_ovl.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
Clean up a stale foreign handle in winnps.c. I had set up an event object for signalling incoming connections to the named pipe, and then called handle_add_foreign_event to get that event object watched for connections - but when I closed down the listening pipe, I deleted the event object without also cancelling that foreign-event handle, so that winhandl.c would potentially call the callback for a destroyed object.
2015-04-07 23:54:41 +03:00
ret->callback_handle =
handle_add_foreign_event(ret->connect_ovl.hEvent,
named_pipe_connect_callback, ret);
Add support for Windows named pipes. This commit adds two new support modules, winnpc.c and winnps.c, which deal respectively with being a client and server of a Windows named pipe (which, in spite of what Unix programmers will infer from that name, is actually closer to Windows's analogue of a Unix-domain socket). Each one provides a fully featured Socket wrapper around the hairy Windows named pipe API, so that the rest of the code base should be able to use these interchangeably with ordinary sockets and hardly notice the difference. As part of this work, I've introduced a mechanism in winhandl.c to permit it to store handles of event objects on behalf of other Windows support modules and deal with passing them to applications' main event loops as necessary. (Perhaps it would have been cleaner to split winhandl.c into an event-object tracking layer analogous to uxsel, and the handle management which is winhandl.c's proper job, but this is less disruptive for the present.) [originally from svn r10069]
2013-11-17 18:04:01 +04:00
named_pipe_accept_loop(ret, FALSE);
cleanup:
return (Socket) ret;
}
#endif /* !defined NO_SECURITY */