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
0.82
putty-source/windows/local-proxy.c

119 lines
3.7 KiB
C
Raw Permalink Normal View History

Fix line endings (svn:eol-style properties and actual CRs). [originally from svn r6817]
2006-08-28 11:13:56 +00:00
/*
Update source file names in comments and docs. Correcting a source file name in the docs just now reminded me that I've seen a lot of outdated source file names elsewhere in the code, due to all the reorganisation since we moved to cmake. Here's a giant pass of trying to make them all accurate again.
2022-01-22 15:38:53 +00:00
* local-proxy.c: Windows implementation of platform_new_connection(),
* supporting an OpenSSH-like proxy command via the handle-io.c
Fix line endings (svn:eol-style properties and actual CRs). [originally from svn r6817]
2006-08-28 11:13:56 +00:00
* mechanism.
*/
#include <stdio.h>
#include <assert.h>
#include "tree234.h"
#include "putty.h"
#include "network.h"
Move proxy-related source files into a subdirectory. There are quite a few of them already, and I'm about to make another one, so let's start with a bit of tidying up. The CMake build organisation is unchanged: I haven't put the proxy object files into a separate library, just moved the locations of the source files. (Organising proxying as a library would be tricky anyway, because of the various overrides for tools that want to avoid cryptography.)
2021-10-30 10:02:28 +00:00
#include "proxy/proxy.h"
Fix line endings (svn:eol-style properties and actual CRs). [originally from svn r6817]
2006-08-28 11:13:56 +00:00
Rewrite local-proxy system to allow interactive prompts. This fills in the remaining gap in the interactive prompt rework of the proxy system in general. If you used the Telnet proxy with a command containing %user or %pass, and hadn't filled in those variables in the PuTTY config, then proxy/telnet.c would prompt you at run time to enter the proxy auth details. But the local proxy command, which uses the same format_telnet_command function, would not do that. Now it does! I've implemented this by moving the formatting of the proxy command into a new module proxy/local.c, shared between both the Unix and Windows local-proxy implementations. That module implements a DeferredSocketOpener, which constructs the proxy command (prompting first if necessary), and once it's constructed, hands it to a per-platform function platform_setup_local_proxy(). So each platform-specific proxy function, instead of starting a subprocess there and then and passing its details to make_fd_socket or make_handle_socket, now returns a _deferred_ version of one of those sockets, with the DeferredSocketOpener being the thing in proxy/local.c. When that calls back to platform_setup_local_proxy(), we actually start the subprocess and pass the resulting fds/handles to the deferred socket to un-defer it. A side effect of the rewrite is that when proxy commands are logged in the Event Log, they now get the same amenities as in the Telnet proxy type: the proxy password is sanitised out, and any difficult characters are escaped.
2021-12-22 12:03:28 +00:00
char *platform_setup_local_proxy(Socket *socket, const char *cmd)
Fix line endings (svn:eol-style properties and actual CRs). [originally from svn r6817]
2006-08-28 11:13:56 +00:00
{
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
HANDLE us_to_cmd, cmd_from_us;
HANDLE us_from_cmd, cmd_to_us;
HANDLE us_from_cmd_err, cmd_err_to_us;
Fix line endings (svn:eol-style properties and actual CRs). [originally from svn r6817]
2006-08-28 11:13:56 +00:00
SECURITY_ATTRIBUTES sa;
STARTUPINFO si;
PROCESS_INFORMATION pi;
/*
* Create the pipes to the proxy command, and spawn the proxy
* command process.
*/
sa.nLength = sizeof(sa);
sa.lpSecurityDescriptor = NULL; /* default */
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 = true;
Fix line endings (svn:eol-style properties and actual CRs). [originally from svn r6817]
2006-08-28 11:13:56 +00:00
if (!CreatePipe(&us_from_cmd, &cmd_to_us, &sa, 0)) {
Rewrite local-proxy system to allow interactive prompts. This fills in the remaining gap in the interactive prompt rework of the proxy system in general. If you used the Telnet proxy with a command containing %user or %pass, and hadn't filled in those variables in the PuTTY config, then proxy/telnet.c would prompt you at run time to enter the proxy auth details. But the local proxy command, which uses the same format_telnet_command function, would not do that. Now it does! I've implemented this by moving the formatting of the proxy command into a new module proxy/local.c, shared between both the Unix and Windows local-proxy implementations. That module implements a DeferredSocketOpener, which constructs the proxy command (prompting first if necessary), and once it's constructed, hands it to a per-platform function platform_setup_local_proxy(). So each platform-specific proxy function, instead of starting a subprocess there and then and passing its details to make_fd_socket or make_handle_socket, now returns a _deferred_ version of one of those sockets, with the DeferredSocketOpener being the thing in proxy/local.c. When that calls back to platform_setup_local_proxy(), we actually start the subprocess and pass the resulting fds/handles to the deferred socket to un-defer it. A side effect of the rewrite is that when proxy commands are logged in the Event Log, they now get the same amenities as in the Telnet proxy type: the proxy password is sanitised out, and any difficult characters are escaped.
2021-12-22 12:03:28 +00:00
return dupprintf("Unable to create pipes for proxy command: %s",
win_strerror(GetLastError()));
Fix line endings (svn:eol-style properties and actual CRs). [originally from svn r6817]
2006-08-28 11:13:56 +00:00
}
if (!CreatePipe(&cmd_from_us, &us_to_cmd, &sa, 0)) {
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
CloseHandle(us_from_cmd);
CloseHandle(cmd_to_us);
Rewrite local-proxy system to allow interactive prompts. This fills in the remaining gap in the interactive prompt rework of the proxy system in general. If you used the Telnet proxy with a command containing %user or %pass, and hadn't filled in those variables in the PuTTY config, then proxy/telnet.c would prompt you at run time to enter the proxy auth details. But the local proxy command, which uses the same format_telnet_command function, would not do that. Now it does! I've implemented this by moving the formatting of the proxy command into a new module proxy/local.c, shared between both the Unix and Windows local-proxy implementations. That module implements a DeferredSocketOpener, which constructs the proxy command (prompting first if necessary), and once it's constructed, hands it to a per-platform function platform_setup_local_proxy(). So each platform-specific proxy function, instead of starting a subprocess there and then and passing its details to make_fd_socket or make_handle_socket, now returns a _deferred_ version of one of those sockets, with the DeferredSocketOpener being the thing in proxy/local.c. When that calls back to platform_setup_local_proxy(), we actually start the subprocess and pass the resulting fds/handles to the deferred socket to un-defer it. A side effect of the rewrite is that when proxy commands are logged in the Event Log, they now get the same amenities as in the Telnet proxy type: the proxy password is sanitised out, and any difficult characters are escaped.
2021-12-22 12:03:28 +00:00
return dupprintf("Unable to create pipes for proxy command: %s",
win_strerror(GetLastError()));
Fix line endings (svn:eol-style properties and actual CRs). [originally from svn r6817]
2006-08-28 11:13:56 +00:00
}
Remove FLAG_STDERR completely. Originally, it controlled whether ssh.c should send terminal messages (such as login and password prompts) to terminal.c or to stderr. But we've had the from_backend() abstraction for ages now, which even has an existing flag to indicate that the data is stderr rather than stdout data; applications which set FLAG_STDERR are precisely those that link against uxcons or wincons, so from_backend will do the expected thing anyway with data sent to it with that flag set. So there's no reason ssh.c can't just unconditionally pass everything through that, and remove the special case. FLAG_STDERR was also used by winproxy and uxproxy to decide whether to capture standard error from a local proxy command, or whether to let the proxy command send its diagnostics directly to the usual standard error. On reflection, I think it's better to unconditionally capture the proxy's stderr, for three reasons. Firstly, it means proxy diagnostics are prefixed with 'proxy:' so that you can tell them apart from any other stderr spew (which used to be particularly confusing if both the main application and the proxy command were instances of Plink); secondly, proxy diagnostics are now reliably copied to packet log files along with all the other Event Log entries, even by command-line tools; and thirdly, this means the option to suppress proxy command diagnostics after the main session starts will actually _work_ in the command-line tools, which it previously couldn't. A more minor structure change is that copying of Event Log messages to stderr in verbose mode is now done by wincons/uxcons, instead of centrally in logging.c (since logging.c can now no longer check FLAG_STDERR to decide whether to do it). The total amount of code to do this is considerably smaller than the defensive-sounding comment in logevent.c explaining why I did it the other way instead :-)
2018-09-21 15:15:49 +00:00
if (!CreatePipe(&us_from_cmd_err, &cmd_err_to_us, &sa, 0)) {
CloseHandle(us_from_cmd);
CloseHandle(cmd_to_us);
CloseHandle(us_to_cmd);
CloseHandle(cmd_from_us);
Rewrite local-proxy system to allow interactive prompts. This fills in the remaining gap in the interactive prompt rework of the proxy system in general. If you used the Telnet proxy with a command containing %user or %pass, and hadn't filled in those variables in the PuTTY config, then proxy/telnet.c would prompt you at run time to enter the proxy auth details. But the local proxy command, which uses the same format_telnet_command function, would not do that. Now it does! I've implemented this by moving the formatting of the proxy command into a new module proxy/local.c, shared between both the Unix and Windows local-proxy implementations. That module implements a DeferredSocketOpener, which constructs the proxy command (prompting first if necessary), and once it's constructed, hands it to a per-platform function platform_setup_local_proxy(). So each platform-specific proxy function, instead of starting a subprocess there and then and passing its details to make_fd_socket or make_handle_socket, now returns a _deferred_ version of one of those sockets, with the DeferredSocketOpener being the thing in proxy/local.c. When that calls back to platform_setup_local_proxy(), we actually start the subprocess and pass the resulting fds/handles to the deferred socket to un-defer it. A side effect of the rewrite is that when proxy commands are logged in the Event Log, they now get the same amenities as in the Telnet proxy type: the proxy password is sanitised out, and any difficult characters are escaped.
2021-12-22 12:03:28 +00:00
return dupprintf("Unable to create pipes for proxy command: %s",
win_strerror(GetLastError()));
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
}
Fix line endings (svn:eol-style properties and actual CRs). [originally from svn r6817]
2006-08-28 11:13:56 +00:00
SetHandleInformation(us_to_cmd, HANDLE_FLAG_INHERIT, 0);
SetHandleInformation(us_from_cmd, HANDLE_FLAG_INHERIT, 0);
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
if (us_from_cmd_err != NULL)
SetHandleInformation(us_from_cmd_err, HANDLE_FLAG_INHERIT, 0);
Fix line endings (svn:eol-style properties and actual CRs). [originally from svn r6817]
2006-08-28 11:13:56 +00:00
si.cb = sizeof(si);
si.lpReserved = NULL;
si.lpDesktop = NULL;
si.lpTitle = NULL;
si.dwFlags = STARTF_USESTDHANDLES;
si.cbReserved2 = 0;
si.lpReserved2 = NULL;
si.hStdInput = cmd_from_us;
si.hStdOutput = cmd_to_us;
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
si.hStdError = cmd_err_to_us;
Rewrite local-proxy system to allow interactive prompts. This fills in the remaining gap in the interactive prompt rework of the proxy system in general. If you used the Telnet proxy with a command containing %user or %pass, and hadn't filled in those variables in the PuTTY config, then proxy/telnet.c would prompt you at run time to enter the proxy auth details. But the local proxy command, which uses the same format_telnet_command function, would not do that. Now it does! I've implemented this by moving the formatting of the proxy command into a new module proxy/local.c, shared between both the Unix and Windows local-proxy implementations. That module implements a DeferredSocketOpener, which constructs the proxy command (prompting first if necessary), and once it's constructed, hands it to a per-platform function platform_setup_local_proxy(). So each platform-specific proxy function, instead of starting a subprocess there and then and passing its details to make_fd_socket or make_handle_socket, now returns a _deferred_ version of one of those sockets, with the DeferredSocketOpener being the thing in proxy/local.c. When that calls back to platform_setup_local_proxy(), we actually start the subprocess and pass the resulting fds/handles to the deferred socket to un-defer it. A side effect of the rewrite is that when proxy commands are logged in the Event Log, they now get the same amenities as in the Telnet proxy type: the proxy password is sanitised out, and any difficult characters are escaped.
2021-12-22 12:03:28 +00:00
char *cmd_mutable = dupstr(cmd); /* CreateProcess needs non-const char * */
CreateProcess(NULL, cmd_mutable, NULL, NULL, true,
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
CREATE_NO_WINDOW | NORMAL_PRIORITY_CLASS,
NULL, NULL, &si, &pi);
Rewrite local-proxy system to allow interactive prompts. This fills in the remaining gap in the interactive prompt rework of the proxy system in general. If you used the Telnet proxy with a command containing %user or %pass, and hadn't filled in those variables in the PuTTY config, then proxy/telnet.c would prompt you at run time to enter the proxy auth details. But the local proxy command, which uses the same format_telnet_command function, would not do that. Now it does! I've implemented this by moving the formatting of the proxy command into a new module proxy/local.c, shared between both the Unix and Windows local-proxy implementations. That module implements a DeferredSocketOpener, which constructs the proxy command (prompting first if necessary), and once it's constructed, hands it to a per-platform function platform_setup_local_proxy(). So each platform-specific proxy function, instead of starting a subprocess there and then and passing its details to make_fd_socket or make_handle_socket, now returns a _deferred_ version of one of those sockets, with the DeferredSocketOpener being the thing in proxy/local.c. When that calls back to platform_setup_local_proxy(), we actually start the subprocess and pass the resulting fds/handles to the deferred socket to un-defer it. A side effect of the rewrite is that when proxy commands are logged in the Event Log, they now get the same amenities as in the Telnet proxy type: the proxy password is sanitised out, and any difficult characters are escaped.
2021-12-22 12:03:28 +00:00
sfree(cmd_mutable);
A user points out that we should free the 'hProcess' and 'hThread' handles returned in the PROCESS_INFORMATION structure after we call CreateProcess. [originally from svn r9686]
2012-10-10 18:29:16 +00:00
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
Fix line endings (svn:eol-style properties and actual CRs). [originally from svn r6817]
2006-08-28 11:13:56 +00:00
CloseHandle(cmd_from_us);
CloseHandle(cmd_to_us);
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
if (cmd_err_to_us != NULL)
CloseHandle(cmd_err_to_us);
Rewrite local-proxy system to allow interactive prompts. This fills in the remaining gap in the interactive prompt rework of the proxy system in general. If you used the Telnet proxy with a command containing %user or %pass, and hadn't filled in those variables in the PuTTY config, then proxy/telnet.c would prompt you at run time to enter the proxy auth details. But the local proxy command, which uses the same format_telnet_command function, would not do that. Now it does! I've implemented this by moving the formatting of the proxy command into a new module proxy/local.c, shared between both the Unix and Windows local-proxy implementations. That module implements a DeferredSocketOpener, which constructs the proxy command (prompting first if necessary), and once it's constructed, hands it to a per-platform function platform_setup_local_proxy(). So each platform-specific proxy function, instead of starting a subprocess there and then and passing its details to make_fd_socket or make_handle_socket, now returns a _deferred_ version of one of those sockets, with the DeferredSocketOpener being the thing in proxy/local.c. When that calls back to platform_setup_local_proxy(), we actually start the subprocess and pass the resulting fds/handles to the deferred socket to un-defer it. A side effect of the rewrite is that when proxy commands are logged in the Event Log, they now get the same amenities as in the Telnet proxy type: the proxy password is sanitised out, and any difficult characters are escaped.
2021-12-22 12:03:28 +00:00
setup_handle_socket(socket, us_to_cmd, us_from_cmd, us_from_cmd_err,
false);
return NULL;
}
Socket *platform_new_connection(SockAddr *addr, const char *hostname,
int port, bool privport,
bool oobinline, bool nodelay, bool keepalive,
Plug *plug, Conf *conf, Interactor *itr)
{
if (conf_get_int(conf, CONF_proxy_type) != PROXY_CMD)
return NULL;
DeferredSocketOpener *opener = local_proxy_opener(
addr, port, plug, conf, itr);
Socket *socket = make_deferred_handle_socket(opener, addr, port, plug);
local_proxy_opener_set_socket(opener, socket);
return socket;
Fix line endings (svn:eol-style properties and actual CRs). [originally from svn r6817]
2006-08-28 11:13:56 +00:00
}
New facility, platform_start_subprocess. We already have the ability to start a subprocess and hook it up to a Socket, for running local proxy commands. Now the same facility is available as an auxiliary feature, so that a backend can start another subcommand for a different purpose, and make a separate Socket to communicate with it. Just like the local proxy system, this facility captures the subprocess's stderr, and passes it back to the caller via plug_log. To make that not look silly, I had to add a system where the "proxy:" prefix on the usual plug_log messages is reconfigurable, and when you call platform_start_subprocess(), you get to pass the prefix you want to use in this case.
2022-08-22 17:46:32 +00:00
Socket *platform_start_subprocess(const char *cmd, Plug *plug,
const char *prefix)
{
Socket *socket = make_deferred_handle_socket(
null_deferred_socket_opener(),
sk_nonamelookup("<local command>"), 0, plug);
char *err = platform_setup_local_proxy(socket, cmd);
handle_socket_set_psb_prefix(socket, prefix);
if (err) {
sk_close(socket);
socket = new_error_socket_fmt(plug, "%s", err);
sfree(err);
}
return socket;
}
Reference in New Issue Copy Permalink