[2/4] GDB: Document the unix::/path/to/socket of remote connection.
Commit Message
gdb/doc:
* gdb.texinfo (Connecting)[Remote Connection Commands]: Provide alternative
unix::/tmp/xxx example. Include @code{unix::@var{local-socket} in
the list of remote and extended-remote syntaxes.
---
gdb/doc/gdb.texinfo | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
Comments
> From: John Darrington <john@darrington.wattle.id.au>
> Cc: John Darrington <john@darrington.wattle.id.au>
> Date: Sat, 13 Oct 2018 19:57:59 +0200
>
> gdb/doc:
> * gdb.texinfo (Connecting)[Remote Connection Commands]: Provide alternative
> unix::/tmp/xxx example. Include @code{unix::@var{local-socket} in
> the list of remote and extended-remote syntaxes.
OK.
On 13/10/18 18:57, John Darrington wrote:
> +Alternatively you can use a Unix domain socket:
> +
> +@smallexample
> +target remote unix::/tmp/gdb-socket1
> +@end smallexample
> +@noindent
> +
> +This has the advantage that it'll not fail if the port number is already
> +in use.
> +
Hi,
I was pointed at this thread by a colleague, because last week I was
also considering submitting a patch to allow gdb and gdbserver to talk
to each other over Unix-domain sockets, and he pointed out that it was
already in progress :-)
I'd like to suggest that this documentation change under-stresses what I
see as the most important reason why this is a useful feature: security.
The gdbserver protocol is cleartext and unauthenticated. Running it on a
TCP port means that anyone who can connect to that port – and depending
on the network environment, that might be a lot of people – can request
gdbserver to execute arbitrary code in the context of the process being
debugged, without having to give a vestige of proof as to their right to
ask for it. This is not really the kind of feature we like about network
protocols in the modern world!
But Unix-domain sockets are access-controlled via the file permissions
on the path leading to the socket file. If you use this new feature to
make a Unix-domain socket inside a directory that only your user id has
access to, then any process physically capable of connecting to the
socket has already proved its right to run code under your user id. So
this solves the whole issue, while keeping all the other conveniences of
the socket-based gdbserver transport.
Also, current versions of OpenSSH support general forwarding of
Unix-domain sockets over SSH connections. Using that, it should even be
possible to use this system for genuinely _remote_ debugging (i.e.
between different machines), without reintroducing the same security
hazard, because the Unix socket at each end is access-controlled, and
the network connection in between them is cryptographically protected.
Cheers,
Simon
On Mon, Oct 15, 2018 at 10:31:01AM +0100, Simon Tatham wrote:
Hi,
I was pointed at this thread by a colleague, because last week I was also
considering submitting a patch to allow gdb and gdbserver to talk to each
other over Unix-domain sockets, and he pointed out that it was already in
progress :-)
I'd like to suggest that this documentation change under-stresses what I
see as the most important reason why this is a useful feature: security.
The gdbserver protocol is cleartext and unauthenticated. Running it on a
TCP port means that anyone who can connect to that port ??? and depending
on the network environment, that might be a lot of people ??? can request
gdbserver to execute arbitrary code in the context of the process being
debugged, without having to give a vestige of proof as to their right to
ask for it. This is not really the kind of feature we like about network
protocols in the modern world!
But Unix-domain sockets are access-controlled via the file permissions on
the path leading to the socket file. If you use this new feature to make
a Unix-domain socket inside a directory that only your user id has access
to, then any process physically capable of connecting to the socket has
already proved its right to run code under your user id. So this solves
the whole issue, while keeping all the other conveniences of the
socket-based gdbserver transport.
Cheers,
Simon
This is a good point. But really it belongs under the heading of the
risks associated with TCP/IP sockets - not the risk which is absent when
using Unix sockets.
The documentation already has this warning:
_Warning:_ 'gdbserver' does not have any built-in security. Do not
run 'gdbserver' connected to any public network; a GDB connection
to 'gdbserver' provides access to the target system with the same
privileges as the user running 'gdbserver'.
... perhaps that could be expanded to discuss the relative merits of
UDS vs. TCP/IP
J'
On Saturday, October 13 2018, John Darrington wrote:
> gdb/doc:
> * gdb.texinfo (Connecting)[Remote Connection Commands]: Provide alternative
> unix::/tmp/xxx example. Include @code{unix::@var{local-socket} in
^
Missing close-curly bracket.
> the list of remote and extended-remote syntaxes.
> ---
> gdb/doc/gdb.texinfo | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index b0dc3bf67c..1e97d692b6 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -20829,6 +20829,15 @@ Note that this command has the same form as the command to connect
> to a serial line. @value{GDBN} will automatically determine which
> kind of file you have specified and will make the appropriate kind
> of connection.
> +The above command is identical to the command:
> +
> +@smallexample
> +target remote unix::/tmp/gdb-socket1
> +@end smallexample
> +@noindent
> +
> +See below for the explanation of this syntax.
> +
> This feature is not available if the host system does not support
> Unix domain sockets.
>
> @@ -20839,6 +20848,7 @@ Unix domain sockets.
> @itemx target remote @code{tcp4:@var{host}:@var{port}}
> @itemx target remote @code{tcp6:@var{host}:@var{port}}
> @itemx target remote @code{tcp6:@var{[host]}:@var{port}}
> +@itemx target remote @code{unix::@var{local-socket}}
> @itemx target extended-remote @code{@var{host}:@var{port}}
> @itemx target extended-remote @code{@var{[host]}:@var{port}}
> @itemx target extended-remote @code{tcp:@var{host}:@var{port}}
> @@ -20846,8 +20856,10 @@ Unix domain sockets.
> @itemx target extended-remote @code{tcp4:@var{host}:@var{port}}
> @itemx target extended-remote @code{tcp6:@var{host}:@var{port}}
> @itemx target extended-remote @code{tcp6:@var{[host]}:@var{port}}
> +@itemx target extended-remote @code{unix::@var{local-socket}}
> @cindex @acronym{TCP} port, @code{target remote}
> -Debug using a @acronym{TCP} connection to @var{port} on @var{host}.
> +Debug using a @acronym{TCP} connection to @var{port} on @var{host}
> +or using the Unix domain socket @var{local-socket} on the local machine.
> The @var{host} may be either a host name, a numeric @acronym{IPv4}
> address, or a numeric @acronym{IPv6} address (with or without the
> square brackets to separate the address from the port); @var{port}
> @@ -20895,6 +20907,16 @@ target remote :1234
> @noindent
>
> Note that the colon is still required here.
> +Alternatively you can use a Unix domain socket:
> +
> +@smallexample
> +target remote unix::/tmp/gdb-socket1
> +@end smallexample
> +@noindent
> +
> +This has the advantage that it'll not fail if the port number is already
> +in use.
> +
>
> @item target remote @code{udp:@var{host}:@var{port}}
> @itemx target remote @code{udp:@var{[host]}:@var{port}}
> --
> 2.11.0
@@ -20829,6 +20829,15 @@ Note that this command has the same form as the command to connect
to a serial line. @value{GDBN} will automatically determine which
kind of file you have specified and will make the appropriate kind
of connection.
+The above command is identical to the command:
+
+@smallexample
+target remote unix::/tmp/gdb-socket1
+@end smallexample
+@noindent
+
+See below for the explanation of this syntax.
+
This feature is not available if the host system does not support
Unix domain sockets.
@@ -20839,6 +20848,7 @@ Unix domain sockets.
@itemx target remote @code{tcp4:@var{host}:@var{port}}
@itemx target remote @code{tcp6:@var{host}:@var{port}}
@itemx target remote @code{tcp6:@var{[host]}:@var{port}}
+@itemx target remote @code{unix::@var{local-socket}}
@itemx target extended-remote @code{@var{host}:@var{port}}
@itemx target extended-remote @code{@var{[host]}:@var{port}}
@itemx target extended-remote @code{tcp:@var{host}:@var{port}}
@@ -20846,8 +20856,10 @@ Unix domain sockets.
@itemx target extended-remote @code{tcp4:@var{host}:@var{port}}
@itemx target extended-remote @code{tcp6:@var{host}:@var{port}}
@itemx target extended-remote @code{tcp6:@var{[host]}:@var{port}}
+@itemx target extended-remote @code{unix::@var{local-socket}}
@cindex @acronym{TCP} port, @code{target remote}
-Debug using a @acronym{TCP} connection to @var{port} on @var{host}.
+Debug using a @acronym{TCP} connection to @var{port} on @var{host}
+or using the Unix domain socket @var{local-socket} on the local machine.
The @var{host} may be either a host name, a numeric @acronym{IPv4}
address, or a numeric @acronym{IPv6} address (with or without the
square brackets to separate the address from the port); @var{port}
@@ -20895,6 +20907,16 @@ target remote :1234
@noindent
Note that the colon is still required here.
+Alternatively you can use a Unix domain socket:
+
+@smallexample
+target remote unix::/tmp/gdb-socket1
+@end smallexample
+@noindent
+
+This has the advantage that it'll not fail if the port number is already
+in use.
+
@item target remote @code{udp:@var{host}:@var{port}}
@itemx target remote @code{udp:@var{[host]}:@var{port}}