Граф коммитов

3 Коммитов

Автор SHA1 Сообщение Дата
Simon Tatham c8f83979a3 Log identifying information for the other end of connections.
When anyone connects to a PuTTY tool's listening socket - whether it's
a user of a local->remote port forwarding, a connection-sharing
downstream or a client of Pageant - we'd like to log as much
information as we can find out about where the connection came from.

To that end, I've implemented a function sk_peer_info() in the socket
abstraction, which returns a freeform text string as best it can (or
NULL, if it can't get anything at all) describing the thing at the
other end of the connection. For TCP connections, this is done using
getpeername() to get an IP address and port in the obvious way; for
Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some
moderately hairy autoconfery) to get the pid and owner of the peer. I
haven't implemented anything for Windows named pipes, but I will if I
hear of anything useful.
2015-05-18 14:03:10 +01:00
Simon Tatham 8be6fbaa09 Remove sk_{get,set}_private_ptr completely!
It was only actually used in X11 and port forwarding, to find internal
state structures given only the Socket that ssh.c held. So now that
that lookup has been reworked to be the sensible way round,
private_ptr is no longer used for anything and can be removed.

[originally from svn r10075]
2013-11-17 14:04:48 +00:00
Simon Tatham a6139c1ad3 Add a Socket implementation which just holds an error message.
This isn't yet used, but I plan to use it in situations where you have
to report errors by returning a valid Socket on which the client wlil
call sk_socket_error, but in fact you notice the error _before_
instantiating your usual kind of Socket. The resulting Socket is
usable for nothing except reading out the error string and closing it.

[originally from svn r10065]
2013-11-17 14:03:36 +00:00