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
b26077b1ae
putty-source/unix/fd-socket.c

418 lines
10 KiB
C
Raw Normal View History

Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +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
* fd-socket.c: implementation of Socket that just talks to two
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
* existing input and output file descriptors.
*/
#include <stdio.h>
#include <assert.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#include "tree234.h"
#include "putty.h"
#include "network.h"
typedef struct FdSocket {
Allow creating FdSocket/HandleSocket before the fds/handles. Previously, a setup function returning one of these socket types (such as platform_new_connection) had to do all its setup synchronously, because if it was going to call make_fd_socket or make_handle_socket, it had to have the actual fds or HANDLEs ready-made. If some kind of asynchronous operation were needed before those fds become available, there would be no way the function could achieve it, except by becoming a whole extra permanent Socket wrapper layer. Now there is, because you can make an FdSocket when you don't yet have the fds, or a HandleSocket without the HANDLEs. Instead, you provide an instance of the new trait 'DeferredSocketOpener', which is responsible for setting in motion whatever asynchronous setup procedure it needs, and when that finishes, calling back to setup_fd_socket / setup_handle_socket to provide the missing pieces. In the meantime, the FdSocket or HandleSocket will sit there inertly, buffering any data the client might eagerly hand it via sk_write(), and waiting for its setup to finish. When it does finish, buffered data will be released. In FdSocket, this is easy enough, because we were doing our own buffering anyway - we called the uxsel system to find out when the fds were readable/writable, and then wrote to them from our own bufchain. So more or less all I had to do was make the try_send function do nothing if the setup phase wasn't finished yet. In HandleSocket, on the other hand, we're passing all our data to the underlying handle-io.c system, and making _that_ deferrable in the same way would be much more painful, because that's the place where the scary threads live. So instead I've arranged it by replacing the whole vtable, so that a deferred HandleSocket and a normal HandleSocket are effectively separate trait implementations that can share their state structure. And in fact that state struct itself now contains a big anonymous union, containing one branch to go with each vtable. Nothing yet uses this system, but the next commit will do so.
2021-12-22 09:31:06 +00:00
int outfd, infd, inerrfd; /* >= 0 if socket is open */
DeferredSocketOpener *opener; /* non-NULL if not opened yet */
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
bufchain pending_output_data;
bufchain pending_input_data;
log_proxy_stderr: limit the length of Event Log lines. If a proxy command jabbers on standard error in a way that doesn't involve any newline characters, we now won't keep buffering data for ever. (Not that I've heard of it happening, but I noticed the theoretical possibility on the way past in a recent cleanup pass.)
2019-03-01 19:18:31 +00:00
ProxyStderrBuf psb;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
enum { EOF_NO, EOF_PENDING, EOF_SENT } outgoingeof;
int pending_error;
FdSocket, HandleSocket: store a notional peer address. In the case where these socket types are constructed because of a local proxy command, we do actually have a SockAddr representing the logical host we were trying to make a connection to. So we might as well store it in the socket implementation, and then we can include it in the PLUGLOG_CONNECT_SUCCESS call to make the log message more informative.
2021-09-13 13:34:46 +00:00
SockAddr *addr;
int port;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
Plug *plug;
Socket sock;
} FdSocket;
static void fdsocket_select_result_input(int fd, int event);
static void fdsocket_select_result_output(int fd, int event);
static void fdsocket_select_result_input_error(int fd, int event);
/*
* Trees to look up the fds in.
*/
static tree234 *fdsocket_by_outfd;
static tree234 *fdsocket_by_infd;
static tree234 *fdsocket_by_inerrfd;
static int fdsocket_infd_cmp(void *av, void *bv)
{
FdSocket *a = (FdSocket *)av;
FdSocket *b = (FdSocket *)bv;
if (a->infd < b->infd)
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
return -1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
if (a->infd > b->infd)
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
return +1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
return 0;
}
static int fdsocket_infd_find(void *av, void *bv)
{
int a = *(int *)av;
FdSocket *b = (FdSocket *)bv;
if (a < b->infd)
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
return -1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
if (a > b->infd)
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
return +1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
return 0;
}
static int fdsocket_inerrfd_cmp(void *av, void *bv)
{
FdSocket *a = (FdSocket *)av;
FdSocket *b = (FdSocket *)bv;
if (a->inerrfd < b->inerrfd)
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
return -1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
if (a->inerrfd > b->inerrfd)
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
return +1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
return 0;
}
static int fdsocket_inerrfd_find(void *av, void *bv)
{
int a = *(int *)av;
FdSocket *b = (FdSocket *)bv;
if (a < b->inerrfd)
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
return -1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
if (a > b->inerrfd)
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
return +1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
return 0;
}
static int fdsocket_outfd_cmp(void *av, void *bv)
{
FdSocket *a = (FdSocket *)av;
FdSocket *b = (FdSocket *)bv;
if (a->outfd < b->outfd)
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
return -1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
if (a->outfd > b->outfd)
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
return +1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
return 0;
}
static int fdsocket_outfd_find(void *av, void *bv)
{
int a = *(int *)av;
FdSocket *b = (FdSocket *)bv;
if (a < b->outfd)
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
return -1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
if (a > b->outfd)
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
return +1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
return 0;
}
static Plug *fdsocket_plug(Socket *s, Plug *p)
{
FdSocket *fds = container_of(s, FdSocket, sock);
Plug *ret = fds->plug;
if (p)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fds->plug = p;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
return ret;
}
static void fdsocket_close(Socket *s)
{
FdSocket *fds = container_of(s, FdSocket, sock);
Allow creating FdSocket/HandleSocket before the fds/handles. Previously, a setup function returning one of these socket types (such as platform_new_connection) had to do all its setup synchronously, because if it was going to call make_fd_socket or make_handle_socket, it had to have the actual fds or HANDLEs ready-made. If some kind of asynchronous operation were needed before those fds become available, there would be no way the function could achieve it, except by becoming a whole extra permanent Socket wrapper layer. Now there is, because you can make an FdSocket when you don't yet have the fds, or a HandleSocket without the HANDLEs. Instead, you provide an instance of the new trait 'DeferredSocketOpener', which is responsible for setting in motion whatever asynchronous setup procedure it needs, and when that finishes, calling back to setup_fd_socket / setup_handle_socket to provide the missing pieces. In the meantime, the FdSocket or HandleSocket will sit there inertly, buffering any data the client might eagerly hand it via sk_write(), and waiting for its setup to finish. When it does finish, buffered data will be released. In FdSocket, this is easy enough, because we were doing our own buffering anyway - we called the uxsel system to find out when the fds were readable/writable, and then wrote to them from our own bufchain. So more or less all I had to do was make the try_send function do nothing if the setup phase wasn't finished yet. In HandleSocket, on the other hand, we're passing all our data to the underlying handle-io.c system, and making _that_ deferrable in the same way would be much more painful, because that's the place where the scary threads live. So instead I've arranged it by replacing the whole vtable, so that a deferred HandleSocket and a normal HandleSocket are effectively separate trait implementations that can share their state structure. And in fact that state struct itself now contains a big anonymous union, containing one branch to go with each vtable. Nothing yet uses this system, but the next commit will do so.
2021-12-22 09:31:06 +00:00
if (fds->opener)
deferred_socket_opener_free(fds->opener);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
if (fds->outfd >= 0) {
del234(fdsocket_by_outfd, fds);
uxsel_del(fds->outfd);
close(fds->outfd);
}
if (fds->infd >= 0) {
del234(fdsocket_by_infd, fds);
uxsel_del(fds->infd);
close(fds->infd);
}
if (fds->inerrfd >= 0) {
del234(fdsocket_by_inerrfd, fds);
uxsel_del(fds->inerrfd);
close(fds->inerrfd);
}
bufchain_clear(&fds->pending_input_data);
bufchain_clear(&fds->pending_output_data);
FdSocket, HandleSocket: store a notional peer address. In the case where these socket types are constructed because of a local proxy command, we do actually have a SockAddr representing the logical host we were trying to make a connection to. So we might as well store it in the socket implementation, and then we can include it in the PLUGLOG_CONNECT_SUCCESS call to make the log message more informative.
2021-09-13 13:34:46 +00:00
if (fds->addr)
sk_addr_free(fds->addr);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
delete_callbacks_for_context(fds);
sfree(fds);
}
static void fdsocket_error_callback(void *vs)
{
FdSocket *fds = (FdSocket *)vs;
/*
* Just in case other socket work has caused this socket to vanish
* or become somehow non-erroneous before this callback arrived...
*/
if (!fds->pending_error)
return;
/*
* An error has occurred on this socket. Pass it to the plug.
*/
Convenience wrappers on plug_closing(). Having a single plug_closing() function covering various kinds of closure is reasonably convenient from the point of view of Plug implementations, but it's annoying for callers, who all have to fill in pointless NULL and 0 parameters in the cases where they're not used. Added some inline helper functions in network.h alongside the main plug_closing() dispatch wrappers, so that each kind of connection closure can present a separate API for the Socket side of the interface, without complicating the vtable for the Plug side. Also, added OS-specific extra helpers in the Unix and Windows directories, which centralise the job of taking an OS error code (of whatever kind) and translating it into its error message. In passing, this removes the horrible ad-hoc made-up error codes in proxy.h, which is OK, because nothing checked for them anyway, and also I'm about to do an API change to plug_closing proper that removes the need for them.
2021-11-06 13:25:42 +00:00
plug_closing_errno(fds->plug, fds->pending_error);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
}
static int fdsocket_try_send(FdSocket *fds)
{
int sent = 0;
Allow creating FdSocket/HandleSocket before the fds/handles. Previously, a setup function returning one of these socket types (such as platform_new_connection) had to do all its setup synchronously, because if it was going to call make_fd_socket or make_handle_socket, it had to have the actual fds or HANDLEs ready-made. If some kind of asynchronous operation were needed before those fds become available, there would be no way the function could achieve it, except by becoming a whole extra permanent Socket wrapper layer. Now there is, because you can make an FdSocket when you don't yet have the fds, or a HandleSocket without the HANDLEs. Instead, you provide an instance of the new trait 'DeferredSocketOpener', which is responsible for setting in motion whatever asynchronous setup procedure it needs, and when that finishes, calling back to setup_fd_socket / setup_handle_socket to provide the missing pieces. In the meantime, the FdSocket or HandleSocket will sit there inertly, buffering any data the client might eagerly hand it via sk_write(), and waiting for its setup to finish. When it does finish, buffered data will be released. In FdSocket, this is easy enough, because we were doing our own buffering anyway - we called the uxsel system to find out when the fds were readable/writable, and then wrote to them from our own bufchain. So more or less all I had to do was make the try_send function do nothing if the setup phase wasn't finished yet. In HandleSocket, on the other hand, we're passing all our data to the underlying handle-io.c system, and making _that_ deferrable in the same way would be much more painful, because that's the place where the scary threads live. So instead I've arranged it by replacing the whole vtable, so that a deferred HandleSocket and a normal HandleSocket are effectively separate trait implementations that can share their state structure. And in fact that state struct itself now contains a big anonymous union, containing one branch to go with each vtable. Nothing yet uses this system, but the next commit will do so.
2021-12-22 09:31:06 +00:00
if (fds->opener)
return sent;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
while (bufchain_size(&fds->pending_output_data) > 0) {
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
ssize_t ret;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
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
ptrlen data = bufchain_prefix(&fds->pending_output_data);
ret = write(fds->outfd, data.ptr, data.len);
Label random-noise sources with an enum of ids. The upcoming PRNG revamp will want to tell noise sources apart, so that it can treat them all fairly. So I've added an extra parameter to noise_ultralight and random_add_noise, which takes values in an enumeration covering all the vague classes of entropy source I'm collecting. In this commit, though, it's simply ignored.
2019-01-22 18:25:54 +00:00
noise_ultralight(NOISE_SOURCE_IOID, ret);
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
if (ret < 0 && errno != EWOULDBLOCK) {
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
if (!fds->pending_error) {
fds->pending_error = errno;
queue_toplevel_callback(fdsocket_error_callback, fds);
}
return 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
} else if (ret <= 0) {
break;
} else {
bufchain_consume(&fds->pending_output_data, ret);
sent += ret;
}
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
}
if (fds->outgoingeof == EOF_PENDING) {
del234(fdsocket_by_outfd, fds);
close(fds->outfd);
uxsel_del(fds->outfd);
fds->outfd = -1;
fds->outgoingeof = EOF_SENT;
}
if (bufchain_size(&fds->pending_output_data) == 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
uxsel_del(fds->outfd);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
else
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
uxsel_set(fds->outfd, SELECT_W, fdsocket_select_result_output);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
return sent;
}
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
static size_t fdsocket_write(Socket *s, const void *data, size_t len)
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
{
FdSocket *fds = container_of(s, FdSocket, sock);
assert(fds->outgoingeof == EOF_NO);
bufchain_add(&fds->pending_output_data, data, len);
fdsocket_try_send(fds);
return bufchain_size(&fds->pending_output_data);
}
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
static size_t fdsocket_write_oob(Socket *s, const void *data, size_t len)
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
{
/*
* oob data is treated as inband; nasty, but nothing really
* better we can do
*/
return fdsocket_write(s, data, len);
}
static void fdsocket_write_eof(Socket *s)
{
FdSocket *fds = container_of(s, FdSocket, sock);
assert(fds->outgoingeof == EOF_NO);
fds->outgoingeof = EOF_PENDING;
fdsocket_try_send(fds);
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void fdsocket_set_frozen(Socket *s, bool is_frozen)
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
{
FdSocket *fds = container_of(s, FdSocket, sock);
if (fds->infd < 0)
return;
if (is_frozen)
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
uxsel_del(fds->infd);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
else
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
uxsel_set(fds->infd, SELECT_R, fdsocket_select_result_input);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
}
static const char *fdsocket_socket_error(Socket *s)
{
return NULL;
}
static void fdsocket_select_result_input(int fd, int event)
{
FdSocket *fds;
char buf[20480];
int retd;
if (!(fds = find234(fdsocket_by_infd, &fd, fdsocket_infd_find)))
return;
retd = read(fds->infd, buf, sizeof(buf));
if (retd > 0) {
plug_receive(fds->plug, 0, buf, retd);
} else {
fd-socket: fix use after free on socket close. The call to plug_closing very likely destroys the FdSocket entirely, so we shouldn't wait until after that to clean up its input fd via lots of dereferences.
2021-09-13 13:18:12 +00:00
del234(fdsocket_by_infd, fds);
uxsel_del(fds->infd);
close(fds->infd);
fds->infd = -1;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
if (retd < 0) {
Convenience wrappers on plug_closing(). Having a single plug_closing() function covering various kinds of closure is reasonably convenient from the point of view of Plug implementations, but it's annoying for callers, who all have to fill in pointless NULL and 0 parameters in the cases where they're not used. Added some inline helper functions in network.h alongside the main plug_closing() dispatch wrappers, so that each kind of connection closure can present a separate API for the Socket side of the interface, without complicating the vtable for the Plug side. Also, added OS-specific extra helpers in the Unix and Windows directories, which centralise the job of taking an OS error code (of whatever kind) and translating it into its error message. In passing, this removes the horrible ad-hoc made-up error codes in proxy.h, which is OK, because nothing checked for them anyway, and also I'm about to do an API change to plug_closing proper that removes the need for them.
2021-11-06 13:25:42 +00:00
plug_closing_errno(fds->plug, errno);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
} else {
Convenience wrappers on plug_closing(). Having a single plug_closing() function covering various kinds of closure is reasonably convenient from the point of view of Plug implementations, but it's annoying for callers, who all have to fill in pointless NULL and 0 parameters in the cases where they're not used. Added some inline helper functions in network.h alongside the main plug_closing() dispatch wrappers, so that each kind of connection closure can present a separate API for the Socket side of the interface, without complicating the vtable for the Plug side. Also, added OS-specific extra helpers in the Unix and Windows directories, which centralise the job of taking an OS error code (of whatever kind) and translating it into its error message. In passing, this removes the horrible ad-hoc made-up error codes in proxy.h, which is OK, because nothing checked for them anyway, and also I'm about to do an API change to plug_closing proper that removes the need for them.
2021-11-06 13:25:42 +00:00
plug_closing_normal(fds->plug);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
}
}
}
static void fdsocket_select_result_output(int fd, int event)
{
FdSocket *fds;
if (!(fds = find234(fdsocket_by_outfd, &fd, fdsocket_outfd_find)))
return;
if (fdsocket_try_send(fds))
plug_sent(fds->plug, bufchain_size(&fds->pending_output_data));
}
static void fdsocket_select_result_input_error(int fd, int event)
{
FdSocket *fds;
char buf[20480];
int retd;
if (!(fds = find234(fdsocket_by_inerrfd, &fd, fdsocket_inerrfd_find)))
return;
retd = read(fd, buf, sizeof(buf));
if (retd > 0) {
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
log_proxy_stderr(fds->plug, &fds->sock, &fds->psb, buf, retd);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
} else {
del234(fdsocket_by_inerrfd, fds);
uxsel_del(fds->inerrfd);
close(fds->inerrfd);
fds->inerrfd = -1;
}
}
static const SocketVtable FdSocket_sockvt = {
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.plug = fdsocket_plug,
.close = fdsocket_close,
.write = fdsocket_write,
.write_oob = fdsocket_write_oob,
.write_eof = fdsocket_write_eof,
.set_frozen = fdsocket_set_frozen,
.socket_error = fdsocket_socket_error,
Centralise stub plug/socket functions. In the previous few commits I noticed some repeated work in the form of pointless empty implementations of Plug's log method, plus some existing (and some new) empty cases of Socket's endpoint_info. As a cleanup, I'm replacing as many as I can find with uses of a central null implementation in the stubs directory.
2024-06-29 11:07:59 +00:00
.endpoint_info = nullsock_endpoint_info,
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
};
Send PLUGLOG_CONNECT_SUCCESS in proxied socket types. Now the non-SSH backends critically depend on it, it's important not to forget to send it, for any socket type that's going to be used for any of those backends. But ProxySocket, and the Unix and Windows 'socket' types wrapping pipes to local subprocesses, were not doing so. Some of these socket types don't have a SockAddr available to represent the destination host. (Sometimes the concept isn't even meaningful). Therefore, I've also expanded the semantics of PLUGLOG_CONNECT_SUCCESS so that the addr parameter is allowed to be NULL, and invented a noncommittal fallback version of the log message in that situation.
2021-09-13 13:28:47 +00:00
static void fdsocket_connect_success_callback(void *ctx)
{
FdSocket *fds = (FdSocket *)ctx;
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(fds->plug, &fds->sock, PLUGLOG_CONNECT_SUCCESS,
fds->addr, fds->port, NULL, 0);
Send PLUGLOG_CONNECT_SUCCESS in proxied socket types. Now the non-SSH backends critically depend on it, it's important not to forget to send it, for any socket type that's going to be used for any of those backends. But ProxySocket, and the Unix and Windows 'socket' types wrapping pipes to local subprocesses, were not doing so. Some of these socket types don't have a SockAddr available to represent the destination host. (Sometimes the concept isn't even meaningful). Therefore, I've also expanded the semantics of PLUGLOG_CONNECT_SUCCESS so that the addr parameter is allowed to be NULL, and invented a noncommittal fallback version of the log message in that situation.
2021-09-13 13:28:47 +00:00
}
Allow creating FdSocket/HandleSocket before the fds/handles. Previously, a setup function returning one of these socket types (such as platform_new_connection) had to do all its setup synchronously, because if it was going to call make_fd_socket or make_handle_socket, it had to have the actual fds or HANDLEs ready-made. If some kind of asynchronous operation were needed before those fds become available, there would be no way the function could achieve it, except by becoming a whole extra permanent Socket wrapper layer. Now there is, because you can make an FdSocket when you don't yet have the fds, or a HandleSocket without the HANDLEs. Instead, you provide an instance of the new trait 'DeferredSocketOpener', which is responsible for setting in motion whatever asynchronous setup procedure it needs, and when that finishes, calling back to setup_fd_socket / setup_handle_socket to provide the missing pieces. In the meantime, the FdSocket or HandleSocket will sit there inertly, buffering any data the client might eagerly hand it via sk_write(), and waiting for its setup to finish. When it does finish, buffered data will be released. In FdSocket, this is easy enough, because we were doing our own buffering anyway - we called the uxsel system to find out when the fds were readable/writable, and then wrote to them from our own bufchain. So more or less all I had to do was make the try_send function do nothing if the setup phase wasn't finished yet. In HandleSocket, on the other hand, we're passing all our data to the underlying handle-io.c system, and making _that_ deferrable in the same way would be much more painful, because that's the place where the scary threads live. So instead I've arranged it by replacing the whole vtable, so that a deferred HandleSocket and a normal HandleSocket are effectively separate trait implementations that can share their state structure. And in fact that state struct itself now contains a big anonymous union, containing one branch to go with each vtable. Nothing yet uses this system, but the next commit will do so.
2021-12-22 09:31:06 +00:00
void setup_fd_socket(Socket *s, int infd, int outfd, int inerrfd)
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
{
Allow creating FdSocket/HandleSocket before the fds/handles. Previously, a setup function returning one of these socket types (such as platform_new_connection) had to do all its setup synchronously, because if it was going to call make_fd_socket or make_handle_socket, it had to have the actual fds or HANDLEs ready-made. If some kind of asynchronous operation were needed before those fds become available, there would be no way the function could achieve it, except by becoming a whole extra permanent Socket wrapper layer. Now there is, because you can make an FdSocket when you don't yet have the fds, or a HandleSocket without the HANDLEs. Instead, you provide an instance of the new trait 'DeferredSocketOpener', which is responsible for setting in motion whatever asynchronous setup procedure it needs, and when that finishes, calling back to setup_fd_socket / setup_handle_socket to provide the missing pieces. In the meantime, the FdSocket or HandleSocket will sit there inertly, buffering any data the client might eagerly hand it via sk_write(), and waiting for its setup to finish. When it does finish, buffered data will be released. In FdSocket, this is easy enough, because we were doing our own buffering anyway - we called the uxsel system to find out when the fds were readable/writable, and then wrote to them from our own bufchain. So more or less all I had to do was make the try_send function do nothing if the setup phase wasn't finished yet. In HandleSocket, on the other hand, we're passing all our data to the underlying handle-io.c system, and making _that_ deferrable in the same way would be much more painful, because that's the place where the scary threads live. So instead I've arranged it by replacing the whole vtable, so that a deferred HandleSocket and a normal HandleSocket are effectively separate trait implementations that can share their state structure. And in fact that state struct itself now contains a big anonymous union, containing one branch to go with each vtable. Nothing yet uses this system, but the next commit will do so.
2021-12-22 09:31:06 +00:00
FdSocket *fds = container_of(s, FdSocket, sock);
assert(fds->sock.vt == &FdSocket_sockvt);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
Allow creating FdSocket/HandleSocket before the fds/handles. Previously, a setup function returning one of these socket types (such as platform_new_connection) had to do all its setup synchronously, because if it was going to call make_fd_socket or make_handle_socket, it had to have the actual fds or HANDLEs ready-made. If some kind of asynchronous operation were needed before those fds become available, there would be no way the function could achieve it, except by becoming a whole extra permanent Socket wrapper layer. Now there is, because you can make an FdSocket when you don't yet have the fds, or a HandleSocket without the HANDLEs. Instead, you provide an instance of the new trait 'DeferredSocketOpener', which is responsible for setting in motion whatever asynchronous setup procedure it needs, and when that finishes, calling back to setup_fd_socket / setup_handle_socket to provide the missing pieces. In the meantime, the FdSocket or HandleSocket will sit there inertly, buffering any data the client might eagerly hand it via sk_write(), and waiting for its setup to finish. When it does finish, buffered data will be released. In FdSocket, this is easy enough, because we were doing our own buffering anyway - we called the uxsel system to find out when the fds were readable/writable, and then wrote to them from our own bufchain. So more or less all I had to do was make the try_send function do nothing if the setup phase wasn't finished yet. In HandleSocket, on the other hand, we're passing all our data to the underlying handle-io.c system, and making _that_ deferrable in the same way would be much more painful, because that's the place where the scary threads live. So instead I've arranged it by replacing the whole vtable, so that a deferred HandleSocket and a normal HandleSocket are effectively separate trait implementations that can share their state structure. And in fact that state struct itself now contains a big anonymous union, containing one branch to go with each vtable. Nothing yet uses this system, but the next commit will do so.
2021-12-22 09:31:06 +00:00
if (fds->opener) {
deferred_socket_opener_free(fds->opener);
fds->opener = NULL;
}
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
fds->infd = infd;
fds->outfd = outfd;
fds->inerrfd = inerrfd;
if (fds->outfd >= 0) {
if (!fdsocket_by_outfd)
fdsocket_by_outfd = newtree234(fdsocket_outfd_cmp);
add234(fdsocket_by_outfd, fds);
}
if (fds->infd >= 0) {
if (!fdsocket_by_infd)
fdsocket_by_infd = newtree234(fdsocket_infd_cmp);
add234(fdsocket_by_infd, fds);
Introduce an enum of the uxsel / select_result flags. Those magic numbers 1,2,4 were getting annoying. Time to replace them while I can still remember what they do.
2019-02-07 18:13:56 +00:00
uxsel_set(fds->infd, SELECT_R, fdsocket_select_result_input);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
}
if (fds->inerrfd >= 0) {
assert(fds->inerrfd != fds->infd);
if (!fdsocket_by_inerrfd)
fdsocket_by_inerrfd = newtree234(fdsocket_inerrfd_cmp);
add234(fdsocket_by_inerrfd, fds);
Introduce an enum of the uxsel / select_result flags. Those magic numbers 1,2,4 were getting annoying. Time to replace them while I can still remember what they do.
2019-02-07 18:13:56 +00:00
uxsel_set(fds->inerrfd, SELECT_R, fdsocket_select_result_input_error);
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
}
Send PLUGLOG_CONNECT_SUCCESS in proxied socket types. Now the non-SSH backends critically depend on it, it's important not to forget to send it, for any socket type that's going to be used for any of those backends. But ProxySocket, and the Unix and Windows 'socket' types wrapping pipes to local subprocesses, were not doing so. Some of these socket types don't have a SockAddr available to represent the destination host. (Sometimes the concept isn't even meaningful). Therefore, I've also expanded the semantics of PLUGLOG_CONNECT_SUCCESS so that the addr parameter is allowed to be NULL, and invented a noncommittal fallback version of the log message in that situation.
2021-09-13 13:28:47 +00:00
queue_toplevel_callback(fdsocket_connect_success_callback, fds);
Allow creating FdSocket/HandleSocket before the fds/handles. Previously, a setup function returning one of these socket types (such as platform_new_connection) had to do all its setup synchronously, because if it was going to call make_fd_socket or make_handle_socket, it had to have the actual fds or HANDLEs ready-made. If some kind of asynchronous operation were needed before those fds become available, there would be no way the function could achieve it, except by becoming a whole extra permanent Socket wrapper layer. Now there is, because you can make an FdSocket when you don't yet have the fds, or a HandleSocket without the HANDLEs. Instead, you provide an instance of the new trait 'DeferredSocketOpener', which is responsible for setting in motion whatever asynchronous setup procedure it needs, and when that finishes, calling back to setup_fd_socket / setup_handle_socket to provide the missing pieces. In the meantime, the FdSocket or HandleSocket will sit there inertly, buffering any data the client might eagerly hand it via sk_write(), and waiting for its setup to finish. When it does finish, buffered data will be released. In FdSocket, this is easy enough, because we were doing our own buffering anyway - we called the uxsel system to find out when the fds were readable/writable, and then wrote to them from our own bufchain. So more or less all I had to do was make the try_send function do nothing if the setup phase wasn't finished yet. In HandleSocket, on the other hand, we're passing all our data to the underlying handle-io.c system, and making _that_ deferrable in the same way would be much more painful, because that's the place where the scary threads live. So instead I've arranged it by replacing the whole vtable, so that a deferred HandleSocket and a normal HandleSocket are effectively separate trait implementations that can share their state structure. And in fact that state struct itself now contains a big anonymous union, containing one branch to go with each vtable. Nothing yet uses this system, but the next commit will do so.
2021-12-22 09:31:06 +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
void fd_socket_set_psb_prefix(Socket *s, const char *prefix)
{
FdSocket *fds = container_of(s, FdSocket, sock);
assert(fds->sock.vt == &FdSocket_sockvt);
psb_set_prefix(&fds->psb, prefix);
}
Allow creating FdSocket/HandleSocket before the fds/handles. Previously, a setup function returning one of these socket types (such as platform_new_connection) had to do all its setup synchronously, because if it was going to call make_fd_socket or make_handle_socket, it had to have the actual fds or HANDLEs ready-made. If some kind of asynchronous operation were needed before those fds become available, there would be no way the function could achieve it, except by becoming a whole extra permanent Socket wrapper layer. Now there is, because you can make an FdSocket when you don't yet have the fds, or a HandleSocket without the HANDLEs. Instead, you provide an instance of the new trait 'DeferredSocketOpener', which is responsible for setting in motion whatever asynchronous setup procedure it needs, and when that finishes, calling back to setup_fd_socket / setup_handle_socket to provide the missing pieces. In the meantime, the FdSocket or HandleSocket will sit there inertly, buffering any data the client might eagerly hand it via sk_write(), and waiting for its setup to finish. When it does finish, buffered data will be released. In FdSocket, this is easy enough, because we were doing our own buffering anyway - we called the uxsel system to find out when the fds were readable/writable, and then wrote to them from our own bufchain. So more or less all I had to do was make the try_send function do nothing if the setup phase wasn't finished yet. In HandleSocket, on the other hand, we're passing all our data to the underlying handle-io.c system, and making _that_ deferrable in the same way would be much more painful, because that's the place where the scary threads live. So instead I've arranged it by replacing the whole vtable, so that a deferred HandleSocket and a normal HandleSocket are effectively separate trait implementations that can share their state structure. And in fact that state struct itself now contains a big anonymous union, containing one branch to go with each vtable. Nothing yet uses this system, but the next commit will do so.
2021-12-22 09:31:06 +00:00
static FdSocket *make_fd_socket_internal(SockAddr *addr, int port, Plug *plug)
{
FdSocket *fds;
Send PLUGLOG_CONNECT_SUCCESS in proxied socket types. Now the non-SSH backends critically depend on it, it's important not to forget to send it, for any socket type that's going to be used for any of those backends. But ProxySocket, and the Unix and Windows 'socket' types wrapping pipes to local subprocesses, were not doing so. Some of these socket types don't have a SockAddr available to represent the destination host. (Sometimes the concept isn't even meaningful). Therefore, I've also expanded the semantics of PLUGLOG_CONNECT_SUCCESS so that the addr parameter is allowed to be NULL, and invented a noncommittal fallback version of the log message in that situation.
2021-09-13 13:28:47 +00:00
Allow creating FdSocket/HandleSocket before the fds/handles. Previously, a setup function returning one of these socket types (such as platform_new_connection) had to do all its setup synchronously, because if it was going to call make_fd_socket or make_handle_socket, it had to have the actual fds or HANDLEs ready-made. If some kind of asynchronous operation were needed before those fds become available, there would be no way the function could achieve it, except by becoming a whole extra permanent Socket wrapper layer. Now there is, because you can make an FdSocket when you don't yet have the fds, or a HandleSocket without the HANDLEs. Instead, you provide an instance of the new trait 'DeferredSocketOpener', which is responsible for setting in motion whatever asynchronous setup procedure it needs, and when that finishes, calling back to setup_fd_socket / setup_handle_socket to provide the missing pieces. In the meantime, the FdSocket or HandleSocket will sit there inertly, buffering any data the client might eagerly hand it via sk_write(), and waiting for its setup to finish. When it does finish, buffered data will be released. In FdSocket, this is easy enough, because we were doing our own buffering anyway - we called the uxsel system to find out when the fds were readable/writable, and then wrote to them from our own bufchain. So more or less all I had to do was make the try_send function do nothing if the setup phase wasn't finished yet. In HandleSocket, on the other hand, we're passing all our data to the underlying handle-io.c system, and making _that_ deferrable in the same way would be much more painful, because that's the place where the scary threads live. So instead I've arranged it by replacing the whole vtable, so that a deferred HandleSocket and a normal HandleSocket are effectively separate trait implementations that can share their state structure. And in fact that state struct itself now contains a big anonymous union, containing one branch to go with each vtable. Nothing yet uses this system, but the next commit will do so.
2021-12-22 09:31:06 +00:00
fds = snew(FdSocket);
fds->sock.vt = &FdSocket_sockvt;
fds->addr = addr;
fds->port = port;
fds->plug = plug;
fds->outgoingeof = EOF_NO;
fds->pending_error = 0;
fds->opener = NULL;
fds->infd = fds->outfd = fds->inerrfd = -1;
bufchain_init(&fds->pending_input_data);
bufchain_init(&fds->pending_output_data);
psb_init(&fds->psb);
return fds;
}
Socket *make_fd_socket(int infd, int outfd, int inerrfd,
SockAddr *addr, int port, Plug *plug)
{
FdSocket *fds = make_fd_socket_internal(addr, port, plug);
setup_fd_socket(&fds->sock, infd, outfd, inerrfd);
return &fds->sock;
}
Socket *make_deferred_fd_socket(DeferredSocketOpener *opener,
SockAddr *addr, int port, Plug *plug)
{
FdSocket *fds = make_fd_socket_internal(addr, port, plug);
fds->opener = opener;
Unix: turn LocalProxySocket into a general FdSocket. The new FdSocket just takes an arbitrary pair of file descriptors to read and write, optionally with an extra input fd providing the standard error output from a command. uxproxy.c now just does the forking and pipe setup, and once it's got all its fds, it hands off to FdSocket to actually do the reading and writing. This is very like the reorganisation I did on the Windows side in commit 98a6a3553 (back in 2013, in preparation for named-pipe sockets and connection sharing). The idea is that it should enable me to make a thing that the PuTTY code base sees as a Socket, but which actually connects to the standard I/O handles of the process it lives in.
2018-10-07 13:55:32 +00:00
return &fds->sock;
}
Reference in New Issue Copy Permalink