2006-08-28 11:13:56 +00:00
|
|
|
/*
|
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
|
2006-08-28 11:13:56 +00:00
|
|
|
* mechanism.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <assert.h>
|
|
|
|
|
|
|
|
|
|
#include "tree234.h"
|
|
|
|
|
#include "putty.h"
|
|
|
|
|
#include "network.h"
|
2021-10-30 10:02:28 +00:00
|
|
|
#include "proxy/proxy.h"
|
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)
|
2006-08-28 11:13:56 +00:00
|
|
|
{
|
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;
|
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 */
|
2018-10-29 19:50:29 +00:00
|
|
|
sa.bInheritHandle = true;
|
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()));
|
2006-08-28 11:13:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!CreatePipe(&cmd_from_us, &us_to_cmd, &sa, 0)) {
|
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()));
|
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()));
|
2015-11-22 11:50:37 +00:00
|
|
|
}
|
|
|
|
|
|
2006-08-28 11:13:56 +00:00
|
|
|
SetHandleInformation(us_to_cmd, HANDLE_FLAG_INHERIT, 0);
|
|
|
|
|
SetHandleInformation(us_from_cmd, HANDLE_FLAG_INHERIT, 0);
|
2015-11-22 11:50:37 +00:00
|
|
|
if (us_from_cmd_err != NULL)
|
|
|
|
|
SetHandleInformation(us_from_cmd_err, HANDLE_FLAG_INHERIT, 0);
|
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;
|
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,
|
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);
|
2012-10-10 18:29:16 +00:00
|
|
|
CloseHandle(pi.hProcess);
|
|
|
|
|
CloseHandle(pi.hThread);
|
2006-08-28 11:13:56 +00:00
|
|
|
|
|
|
|
|
CloseHandle(cmd_from_us);
|
|
|
|
|
CloseHandle(cmd_to_us);
|
|
|
|
|
|
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;
|
2006-08-28 11:13:56 +00:00
|
|
|
}
|
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;
|
|
|
|
|
}
|