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
pre-0.83
putty-source/proxy/local.c

274 lines
8.9 KiB
C
Raw Permalink Normal View History

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
/*
* Implement LocalProxyOpener, a centralised system for setting up the
* command string to be run by platform-specific local-subprocess
* proxy types.
*
* The platform-specific local proxy code is expected to use this
* system by calling local_proxy_opener() from
* platform_new_connection(); then using the resulting
* DeferredSocketOpener to make a deferred version of whatever local
* socket type is used for talking to subcommands (Unix FdSocket,
* Windows HandleSocket); then passing the 'Socket *' back to us via
* local_proxy_opener_set_socket().
*
* The LocalProxyOpener object implemented by this code will set
* itself up as an Interactor if possible, so that it can prompt for
* the proxy username and/or password if they're referred to in the
* command string but not given in the config (exactly as the Telnet
* proxy does). Once it knows the exact command it wants to run -
* whether that was done immediately or after user interaction - it
* calls back to platform_setup_local_proxy() with the full command,
* which is expected to actually start the subprocess and fill in the
* missing details in the deferred socket, freeing the
* LocalProxyOpener as a side effect.
*/
#include "tree234.h"
#include "putty.h"
#include "network.h"
#include "sshcr.h"
#include "proxy/proxy.h"
typedef struct LocalProxyOpener {
int crLine;
Socket *socket;
char *formatted_cmd;
Plug *plug;
SockAddr *addr;
int port;
Conf *conf;
Interactor *clientitr;
LogPolicy *clientlp;
Seat *clientseat;
prompts_t *prompts;
int username_prompt_index, password_prompt_index;
Interactor interactor;
DeferredSocketOpener opener;
} LocalProxyOpener;
static void local_proxy_opener_free(DeferredSocketOpener *opener)
{
LocalProxyOpener *lp = container_of(opener, LocalProxyOpener, opener);
burnstr(lp->formatted_cmd);
if (lp->prompts)
free_prompts(lp->prompts);
sk_addr_free(lp->addr);
conf_free(lp->conf);
sfree(lp);
}
static const DeferredSocketOpenerVtable LocalProxyOpener_openervt = {
.free = local_proxy_opener_free,
};
static char *local_proxy_opener_description(Interactor *itr)
{
return dupstr("connection via local command");
}
static LogPolicy *local_proxy_opener_logpolicy(Interactor *itr)
{
LocalProxyOpener *lp = container_of(itr, LocalProxyOpener, interactor);
return lp->clientlp;
}
static Seat *local_proxy_opener_get_seat(Interactor *itr)
{
LocalProxyOpener *lp = container_of(itr, LocalProxyOpener, interactor);
return lp->clientseat;
}
static void local_proxy_opener_set_seat(Interactor *itr, Seat *seat)
{
LocalProxyOpener *lp = container_of(itr, LocalProxyOpener, interactor);
lp->clientseat = seat;
}
static const InteractorVtable LocalProxyOpener_interactorvt = {
.description = local_proxy_opener_description,
.logpolicy = local_proxy_opener_logpolicy,
.get_seat = local_proxy_opener_get_seat,
.set_seat = local_proxy_opener_set_seat,
};
static void local_proxy_opener_cleanup_interactor(LocalProxyOpener *lp)
{
if (lp->clientseat) {
interactor_return_seat(lp->clientitr);
lp->clientitr = NULL;
lp->clientseat = NULL;
}
}
static void local_proxy_opener_coroutine(void *vctx)
{
LocalProxyOpener *lp = (LocalProxyOpener *)vctx;
crBegin(lp->crLine);
/*
* Make an initial attempt to figure out the command we want, and
* see if it tried to include a username or password that we don't
* have.
*/
{
unsigned flags;
lp->formatted_cmd = format_telnet_command(
lp->addr, lp->port, lp->conf, &flags);
if (lp->clientseat && (flags & (TELNET_CMD_MISSING_USERNAME |
TELNET_CMD_MISSING_PASSWORD))) {
burnstr(lp->formatted_cmd);
lp->formatted_cmd = NULL;
/*
* We're missing at least one of the two parts, and we
* have an Interactor we can use to prompt for them, so
* try it.
*/
lp->prompts = new_prompts();
lp->prompts->callback = local_proxy_opener_coroutine;
lp->prompts->callback_ctx = lp;
lp->prompts->to_server = true;
lp->prompts->from_server = false;
lp->prompts->name = dupstr("Local proxy authentication");
if (flags & TELNET_CMD_MISSING_USERNAME) {
lp->username_prompt_index = lp->prompts->n_prompts;
add_prompt(lp->prompts, dupstr("Proxy username: "), true);
} else {
lp->username_prompt_index = -1;
}
if (flags & TELNET_CMD_MISSING_PASSWORD) {
lp->password_prompt_index = lp->prompts->n_prompts;
add_prompt(lp->prompts, dupstr("Proxy password: "), false);
} else {
lp->password_prompt_index = -1;
}
while (true) {
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
SeatPromptResult spr = seat_get_userpass_input(
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
interactor_announce(&lp->interactor), lp->prompts);
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
if (spr.kind == SPRK_OK) {
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
break;
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
} else if (spr.kind == SPRK_USER_ABORT) {
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
local_proxy_opener_cleanup_interactor(lp);
plug_closing_user_abort(lp->plug);
/* That will have freed us, so we must just return
* without calling any crStop */
return;
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
} else if (spr.kind == SPRK_SW_ABORT) {
local_proxy_opener_cleanup_interactor(lp);
char *err = spr_get_error_message(spr);
plug_closing_error(lp->plug, err);
sfree(err);
return; /* without crStop, as above */
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
}
crReturnV;
}
if (lp->username_prompt_index != -1) {
conf_set_str(
lp->conf, CONF_proxy_username,
prompt_get_result_ref(
lp->prompts->prompts[lp->username_prompt_index]));
}
if (lp->password_prompt_index != -1) {
conf_set_str(
lp->conf, CONF_proxy_password,
prompt_get_result_ref(
lp->prompts->prompts[lp->password_prompt_index]));
}
free_prompts(lp->prompts);
lp->prompts = NULL;
}
/*
* Now format the command a second time, with the results of
* those prompts written into lp->conf.
*/
lp->formatted_cmd = format_telnet_command(
lp->addr, lp->port, lp->conf, NULL);
}
/*
* Log the command, with some changes. Firstly, we regenerate it
* with the password masked; secondly, we escape control
* characters so that the log message is printable.
*/
conf_set_str(lp->conf, CONF_proxy_password, "*password*");
{
char *censored_cmd = format_telnet_command(
lp->addr, lp->port, lp->conf, NULL);
strbuf *logmsg = strbuf_new();
put_datapl(logmsg, PTRLEN_LITERAL("Starting local proxy command: "));
put_c_string_literal(logmsg, ptrlen_from_asciz(censored_cmd));
Pass the calling Socket to plug_log. This enables plug_log to run query methods on the socket in order to find out useful information to log. I don't expect it's sensible to do anything else with it.
2024-06-26 07:29:39 +00:00
plug_log(lp->plug, lp->socket, PLUGLOG_PROXY_MSG, NULL, 0,
logmsg->s, 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
strbuf_free(logmsg);
sfree(censored_cmd);
}
/*
* Now we're ready to actually do the platform-specific socket
* setup.
*/
char *cmd = lp->formatted_cmd;
lp->formatted_cmd = NULL;
local_proxy_opener_cleanup_interactor(lp);
char *error_msg = platform_setup_local_proxy(lp->socket, cmd);
burnstr(cmd);
if (error_msg) {
plug_closing_error(lp->plug, error_msg);
sfree(error_msg);
} else {
/* If error_msg was NULL, there was no error in setup,
* which means that platform_setup_local_proxy will have
* called back to free us. So return without calling any
* crStop. */
return;
}
crFinishV;
}
DeferredSocketOpener *local_proxy_opener(
SockAddr *addr, int port, Plug *plug, Conf *conf, Interactor *itr)
{
LocalProxyOpener *lp = snew(LocalProxyOpener);
memset(lp, 0, sizeof(*lp));
lp->plug = plug;
lp->opener.vt = &LocalProxyOpener_openervt;
lp->interactor.vt = &LocalProxyOpener_interactorvt;
lp->addr = sk_addr_dup(addr);
lp->port = port;
lp->conf = conf_copy(conf);
if (itr) {
lp->clientitr = itr;
interactor_set_child(lp->clientitr, &lp->interactor);
lp->clientlp = interactor_logpolicy(lp->clientitr);
lp->clientseat = interactor_borrow_seat(lp->clientitr);
}
return &lp->opener;
}
void local_proxy_opener_set_socket(DeferredSocketOpener *opener,
Socket *socket)
{
assert(opener->vt == &LocalProxyOpener_openervt);
LocalProxyOpener *lp = container_of(opener, LocalProxyOpener, opener);
lp->socket = socket;
queue_toplevel_callback(local_proxy_opener_coroutine, lp);
}
Reference in New Issue Copy Permalink