nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
f317f8e67e
putty-source/windows/named-pipe-server.c

236 lines
6.5 KiB
C
Raw Normal View History

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 14:04:01 +00:00
/*
* Windows support module which deals with being a named-pipe server.
*/
#include <stdio.h>
#include <assert.h>
#include "tree234.h"
#include "putty.h"
#include "network.h"
#include "proxy.h"
#include "ssh.h"
Rename most of the platform source files. This gets rid of all those annoying 'win', 'ux' and 'gtk' prefixes which made filenames annoying to type and to tab-complete. Also, as with my other recent renaming sprees, I've taken the opportunity to expand and clarify some of the names so that they're not such cryptic abbreviations.
2021-04-23 05:19:05 +00:00
#include "security-api.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 14:04:01 +00:00
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
typedef struct NamedPipeServerSocket {
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 14:04:01 +00:00
/* 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;
Reorganise Windows HANDLE management. Before commit 6e69223dc262755, Pageant would stop working after a certain number of PuTTYs were active at the same time. (At most about 60, but maybe fewer - see below.) This was because of two separate bugs. The easy one, fixed in 6e69223dc262755 itself, was that PuTTY left each named-pipe connection to Pageant open for the rest of its lifetime. So the real problem was that Pageant had too many active connections at once. (And since a given PuTTY might make multiple connections during userauth - one to list keys, and maybe another to actually make a signature - that was why the number of _PuTTYs_ might vary.) It was clearly a bug that PuTTY was leaving connections to Pageant needlessly open. But it was _also_ a bug that Pageant couldn't handle more than about 60 at once. In this commit, I fix that secondary bug. The cause of the bug is that the WaitForMultipleObjects function family in the Windows API have a limit on the number of HANDLE objects they can select between. The limit is MAXIMUM_WAIT_OBJECTS, defined to be 64. And handle-io.c was using a separate event object for each I/O subthread to communicate back to the main thread, so as soon as all those event objects (plus a handful of other HANDLEs) added up to more than 64, we'd start passing an overlarge handle array to WaitForMultipleObjects, and it would start not doing what we wanted. To fix this, I've reorganised handle-io.c so that all its subthreads share just _one_ event object to signal readiness back to the main thread. There's now a linked list of 'struct handle' objects that are ready to be processed, protected by a CRITICAL_SECTION. Each subthread signals readiness by adding itself to the linked list, and setting the event object to indicate that the list is now non-empty. When the main thread receives the event, it iterates over the whole list processing all the ready handles. (Each 'struct handle' still has a separate event object for the main thread to use to communicate _to_ the subthread. That's OK, because no thread is ever waiting on all those events at once: each subthread only waits on its own.) The previous HT_FOREIGN system didn't really fit into this framework. So I've moved it out into its own system. There's now a handle-wait.c which deals with the relatively simple job of managing a list of handles that need to be waited for, each with a callback function; that's what communicates a list of HANDLEs to event loops, and receives the notification when the event loop notices that one of them has done something. And handle-io.c is now just one client of handle-wait.c, providing a single HANDLE to the event loop, and dealing internally with everything that needs to be done when that handle fires. The new top-level handle-wait.c system *still* can't deal with more than MAXIMUM_WAIT_OBJECTS. At the moment, I'm reasonably convinced it doesn't need to: the only kind of HANDLE that any of our tools could previously have needed to wait on more than one of was the one in handle-io.c that I've just removed. But I've left some assertions and a TODO comment in there just in case we need to change that in future.
2021-05-24 12:06:10 +00:00
HandleWait *callback_handle; /* handle-wait.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 14:04:01 +00:00
/* PuTTY Socket machinery */
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Plug *plug;
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 14:04:01 +00:00
char *error;
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
Socket sock;
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
} NamedPipeServerSocket;
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 14:04:01 +00:00
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static Plug *sk_namedpipeserver_plug(Socket *s, Plug *p)
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 14:04:01 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
NamedPipeServerSocket *ps = container_of(s, NamedPipeServerSocket, sock);
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Plug *ret = ps->plug;
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 14:04:01 +00:00
if (p)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ps->plug = p;
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 14:04:01 +00:00
return ret;
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void sk_namedpipeserver_close(Socket *s)
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 14:04:01 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
NamedPipeServerSocket *ps = container_of(s, NamedPipeServerSocket, sock);
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 14:04:01 +00:00
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 20:54:41 +00:00
if (ps->callback_handle)
Reorganise Windows HANDLE management. Before commit 6e69223dc262755, Pageant would stop working after a certain number of PuTTYs were active at the same time. (At most about 60, but maybe fewer - see below.) This was because of two separate bugs. The easy one, fixed in 6e69223dc262755 itself, was that PuTTY left each named-pipe connection to Pageant open for the rest of its lifetime. So the real problem was that Pageant had too many active connections at once. (And since a given PuTTY might make multiple connections during userauth - one to list keys, and maybe another to actually make a signature - that was why the number of _PuTTYs_ might vary.) It was clearly a bug that PuTTY was leaving connections to Pageant needlessly open. But it was _also_ a bug that Pageant couldn't handle more than about 60 at once. In this commit, I fix that secondary bug. The cause of the bug is that the WaitForMultipleObjects function family in the Windows API have a limit on the number of HANDLE objects they can select between. The limit is MAXIMUM_WAIT_OBJECTS, defined to be 64. And handle-io.c was using a separate event object for each I/O subthread to communicate back to the main thread, so as soon as all those event objects (plus a handful of other HANDLEs) added up to more than 64, we'd start passing an overlarge handle array to WaitForMultipleObjects, and it would start not doing what we wanted. To fix this, I've reorganised handle-io.c so that all its subthreads share just _one_ event object to signal readiness back to the main thread. There's now a linked list of 'struct handle' objects that are ready to be processed, protected by a CRITICAL_SECTION. Each subthread signals readiness by adding itself to the linked list, and setting the event object to indicate that the list is now non-empty. When the main thread receives the event, it iterates over the whole list processing all the ready handles. (Each 'struct handle' still has a separate event object for the main thread to use to communicate _to_ the subthread. That's OK, because no thread is ever waiting on all those events at once: each subthread only waits on its own.) The previous HT_FOREIGN system didn't really fit into this framework. So I've moved it out into its own system. There's now a handle-wait.c which deals with the relatively simple job of managing a list of handles that need to be waited for, each with a callback function; that's what communicates a list of HANDLEs to event loops, and receives the notification when the event loop notices that one of them has done something. And handle-io.c is now just one client of handle-wait.c, providing a single HANDLE to the event loop, and dealing internally with everything that needs to be done when that handle fires. The new top-level handle-wait.c system *still* can't deal with more than MAXIMUM_WAIT_OBJECTS. At the moment, I'm reasonably convinced it doesn't need to: the only kind of HANDLE that any of our tools could previously have needed to wait on more than one of was the one in handle-io.c that I've just removed. But I've left some assertions and a TODO comment in there just in case we need to change that in future.
2021-05-24 12:06:10 +00:00
delete_handle_wait(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 14:04:01 +00: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);
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static const char *sk_namedpipeserver_socket_error(Socket *s)
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 14:04:01 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
NamedPipeServerSocket *ps = container_of(s, NamedPipeServerSocket, sock);
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 14:04:01 +00:00
return ps->error;
}
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
static SocketPeerInfo *sk_namedpipeserver_peer_info(Socket *s)
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 12:57:45 +00:00
{
return NULL;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool create_named_pipe(NamedPipeServerSocket *ps, bool first_instance)
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 14:04:01 +00:00
{
SECURITY_ATTRIBUTES sa;
memset(&sa, 0, sizeof(sa));
sa.nLength = sizeof(sa);
sa.lpSecurityDescriptor = ps->psd;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
sa.bInheritHandle = false;
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 14:04:01 +00:00
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;
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static Socket *named_pipe_accept(accept_ctx_t ctx, Plug *plug)
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 14:04:01 +00:00
{
HANDLE conn = (HANDLE)ctx.p;
FdSocket, HandleSocket: store a notional peer address. In the case where these socket types are constructed because of a local proxy command, we do actually have a SockAddr representing the logical host we were trying to make a connection to. So we might as well store it in the socket implementation, and then we can include it in the PLUGLOG_CONNECT_SUCCESS call to make the log message more informative.
2021-09-13 13:34:46 +00:00
return make_handle_socket(conn, conn, NULL, NULL, 0, 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 14:04:01 +00:00
}
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
static void named_pipe_accept_loop(NamedPipeServerSocket *ps,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool got_one_already)
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 14:04:01 +00:00
{
while (1) {
int error;
char *errmsg;
if (got_one_already) {
/* If we were called with a connection already waiting,
* skip this step. */
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
got_one_already = false;
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 14:04:01 +00:00
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);
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
if (!create_named_pipe(ps, false)) {
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 14:04:01 +00:00
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 14:05:41 +00: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 14:04:01 +00:00
errmsg, error);
sfree(errmsg);
break;
}
}
static void named_pipe_connect_callback(void *vps)
{
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
NamedPipeServerSocket *ps = (NamedPipeServerSocket *)vps;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
named_pipe_accept_loop(ps, 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 14:04:01 +00:00
}
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
/*
* This socket type is only used for listening, so it should never
Completely remove sk_flush(). I've only just noticed that it doesn't do anything at all! Almost every implementation of the Socket vtable provides a flush() method which does nothing, optionally with a comment explaining why it's OK to do nothing. The sole exception is the wrapper Proxy_Socket, which implements the method during its setup phase by setting a pending_flush flag, so that when its sub-socket is later created, it can call sk_flush on that. But since the sub-socket's sk_flush will do nothing, even that is completely pointless! Source control history says that sk_flush was introduced by Dave Hinton in 2001 (commit 7b0e08270), who was going to use it for some purpose involving the SSL Telnet support he was working on at the time. That SSL support was never finished, and its vestigial declarations in network.h were removed in 2015 (commit 42334b65b). So sk_flush is just another vestige of that abandoned work, which I should have removed in the latter commit but overlooked.
2019-07-28 09:32:17 +00:00
* be asked to write or set_frozen.
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
*/
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 06:03:46 +00:00
static const SocketVtable NamedPipeServerSocket_sockvt = {
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.plug = sk_namedpipeserver_plug,
.close = sk_namedpipeserver_close,
.socket_error = sk_namedpipeserver_socket_error,
.peer_info = sk_namedpipeserver_peer_info,
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
};
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Socket *new_named_pipe_listener(const char *pipename, Plug *plug)
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 14:04:01 +00:00
{
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
NamedPipeServerSocket *ret = snew(NamedPipeServerSocket);
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
ret->sock.vt = &NamedPipeServerSocket_sockvt;
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 14:04:01 +00:00
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 20:54:41 +00: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 14:04:01 +00: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 14:05:41 +00: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 18:35:14 +00: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 14:04:01 +00:00
goto cleanup;
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
if (!create_named_pipe(ret, 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 14:04:01 +00:00
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));
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret->connect_ovl.hEvent = CreateEvent(NULL, true, false, NULL);
Reorganise Windows HANDLE management. Before commit 6e69223dc262755, Pageant would stop working after a certain number of PuTTYs were active at the same time. (At most about 60, but maybe fewer - see below.) This was because of two separate bugs. The easy one, fixed in 6e69223dc262755 itself, was that PuTTY left each named-pipe connection to Pageant open for the rest of its lifetime. So the real problem was that Pageant had too many active connections at once. (And since a given PuTTY might make multiple connections during userauth - one to list keys, and maybe another to actually make a signature - that was why the number of _PuTTYs_ might vary.) It was clearly a bug that PuTTY was leaving connections to Pageant needlessly open. But it was _also_ a bug that Pageant couldn't handle more than about 60 at once. In this commit, I fix that secondary bug. The cause of the bug is that the WaitForMultipleObjects function family in the Windows API have a limit on the number of HANDLE objects they can select between. The limit is MAXIMUM_WAIT_OBJECTS, defined to be 64. And handle-io.c was using a separate event object for each I/O subthread to communicate back to the main thread, so as soon as all those event objects (plus a handful of other HANDLEs) added up to more than 64, we'd start passing an overlarge handle array to WaitForMultipleObjects, and it would start not doing what we wanted. To fix this, I've reorganised handle-io.c so that all its subthreads share just _one_ event object to signal readiness back to the main thread. There's now a linked list of 'struct handle' objects that are ready to be processed, protected by a CRITICAL_SECTION. Each subthread signals readiness by adding itself to the linked list, and setting the event object to indicate that the list is now non-empty. When the main thread receives the event, it iterates over the whole list processing all the ready handles. (Each 'struct handle' still has a separate event object for the main thread to use to communicate _to_ the subthread. That's OK, because no thread is ever waiting on all those events at once: each subthread only waits on its own.) The previous HT_FOREIGN system didn't really fit into this framework. So I've moved it out into its own system. There's now a handle-wait.c which deals with the relatively simple job of managing a list of handles that need to be waited for, each with a callback function; that's what communicates a list of HANDLEs to event loops, and receives the notification when the event loop notices that one of them has done something. And handle-io.c is now just one client of handle-wait.c, providing a single HANDLE to the event loop, and dealing internally with everything that needs to be done when that handle fires. The new top-level handle-wait.c system *still* can't deal with more than MAXIMUM_WAIT_OBJECTS. At the moment, I'm reasonably convinced it doesn't need to: the only kind of HANDLE that any of our tools could previously have needed to wait on more than one of was the one in handle-io.c that I've just removed. But I've left some assertions and a TODO comment in there just in case we need to change that in future.
2021-05-24 12:06:10 +00:00
ret->callback_handle = add_handle_wait(
ret->connect_ovl.hEvent, named_pipe_connect_callback, ret);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
named_pipe_accept_loop(ret, false);
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 14:04:01 +00:00
cleanup:
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
return &ret->sock;
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 14:04:01 +00:00
}
Reference in New Issue Copy Permalink