nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 09:58:01 +00:00
Code Issues Projects Releases Wiki Activity
0bbe87f11e
putty-source/windows/winnpc.c

99 lines
2.9 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 client.
*/
#include <stdio.h>
#include <assert.h>
#include "tree234.h"
#include "putty.h"
#include "network.h"
#include "proxy.h"
#include "ssh.h"
#if !defined NO_SECURITY
Move the dynamic loading of advapi into its own module. There's now a winsecur.[ch], which centralises helper functions using the Windows security stuff in advapi.h (currently just get_user_sid), and also centralises the run-time loading of those functions and checking they're all there. [originally from svn r10082]
2013-11-17 14:05:29 +00: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 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
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 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
Socket *new_named_pipe_client(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
{
HANDLE pipehandle;
PSID usersid, pipeowner;
PSECURITY_DESCRIPTOR psd;
char *err;
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 *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 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
while (1) {
pipehandle = CreateFile(pipename, GENERIC_READ | GENERIC_WRITE,
0, NULL, OPEN_EXISTING,
FILE_FLAG_OVERLAPPED, 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
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 (pipehandle != INVALID_HANDLE_VALUE)
break;
if (GetLastError() != ERROR_PIPE_BUSY) {
err = dupprintf("Unable to open named pipe '%s': %s",
pipename, win_strerror(GetLastError()));
ret = new_error_socket(err, plug);
sfree(err);
return ret;
}
/*
* If we got ERROR_PIPE_BUSY, wait for the server to
* create a new pipe instance. (Since the server is
* expected to be winnps.c, which will do that immediately
* after a previous connection is accepted, that shouldn't
* take excessively long.)
*/
if (!WaitNamedPipe(pipename, NMPWAIT_USE_DEFAULT_WAIT)) {
err = dupprintf("Error waiting for named pipe '%s': %s",
pipename, win_strerror(GetLastError()));
ret = new_error_socket(err, plug);
sfree(err);
return 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 14:04:01 +00:00
}
if ((usersid = get_user_sid()) == NULL) {
CloseHandle(pipehandle);
err = dupprintf("Unable to get user SID");
ret = new_error_socket(err, plug);
sfree(err);
return ret;
}
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 (p_GetSecurityInfo(pipehandle, SE_KERNEL_OBJECT,
OWNER_SECURITY_INFORMATION,
&pipeowner, NULL, NULL, NULL,
&psd) != ERROR_SUCCESS) {
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
err = dupprintf("Unable to get named pipe security information: %s",
win_strerror(GetLastError()));
ret = new_error_socket(err, plug);
sfree(err);
CloseHandle(pipehandle);
return ret;
}
if (!EqualSid(pipeowner, usersid)) {
err = dupprintf("Owner of named pipe '%s' is not us", pipename);
ret = new_error_socket(err, plug);
sfree(err);
CloseHandle(pipehandle);
LocalFree(psd);
return ret;
}
LocalFree(psd);
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 11:50:37 +00:00
return make_handle_socket(pipehandle, pipehandle, 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 14:04:01 +00:00
}
#endif /* !defined NO_SECURITY */
Reference in New Issue Copy Permalink