1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 09:58:01 +00:00
Commit Graph

6 Commits

Author SHA1 Message Date
Simon Tatham
984fe3dde8 Merge branch 'pre-0.67' 2016-02-29 19:59:59 +00:00
Simon Tatham
9c6a600e5b Make get_user_sid() return the cached copy if one already exists.
A user reported in January that locking down our process ACL causes
get_user_sid's call to OpenProcessToken to fail with a permissions
error. This _shouldn't_ be important, because we'll already have found
and cached the user SID before getting that far - but unfortunately
the call to get_user_sid in winnpc.c was bypassing the cache and
trying the whole process again.

This fix changes the memory ownership semantics of get_user_sid():
it's now an error to free the value it gives you, or else the *next*
call to get_user_sid() will return a stale pointer. Hence, also
removed those frees everywhere they appear.
2016-02-29 19:59:37 +00:00
Simon Tatham
297efff303 In GUI PuTTY, log standard error from local proxy commands.
On both Unix and Windows, we now redirect the local proxy command's
standard error into a third pipe; data received from that pipe is
broken up at newlines and logged in the Event Log. So if the proxy
command emits any error messages in the course of failing to connect
to something, you now have a fighting chance of finding out what went
wrong.

This feature is disabled in command-line tools like PSFTP and Plink,
on the basis that in that situation it seems more likely that the user
would expect standard-error output to go to the ordinary standard
error in the ordinary way. Only GUI PuTTY catches it and logs it like
this, because it either doesn't have a standard error at all (on
Windows) or is likely to be pointing it at some completely unhelpful
session log file (under X).
2015-11-22 15:11:00 +00:00
Simon Tatham
bb78583ad2 Implement connection sharing between instances of PuTTY.
The basic strategy is described at the top of the new source file
sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain
socket or Windows named pipe, and listens for connections from other
PuTTYs wanting to run sessions on the same server. The protocol spoken
down that socket/pipe is essentially the bare ssh-connection protocol,
using a trivial binary packet protocol with no encryption, and the
upstream has to do some fiddly transformations that I've been
referring to as 'channel-number NAT' to avoid resource clashes between
the sessions it's managing.

This is quite different from OpenSSH's approach of using the Unix-
domain socket as a means of passing file descriptors around; the main
reason for that is that fd-passing is Unix-specific but this system
has to work on Windows too. However, there are additional advantages,
such as making it easy for each downstream PuTTY to run its own
independent set of port and X11 forwardings (though the method for
making the latter work is quite painful).

Sharing is off by default, but configuration is intended to be very
easy in the normal case - just tick one box in the SSH config panel
and everything else happens automatically.

[originally from svn r10083]
2013-11-17 14:05:41 +00:00
Simon Tatham
f6f78f8355 Move the dynamic loading of advapi into its own module.
There's now a winsecur.[ch], which centralises helper functions using
the Windows security stuff in advapi.h (currently just get_user_sid),
and also centralises the run-time loading of those functions and
checking they're all there.

[originally from svn r10082]
2013-11-17 14:05:29 +00:00
Simon Tatham
1b3edafcff Add support for Windows named pipes.
This commit adds two new support modules, winnpc.c and winnps.c, which
deal respectively with being a client and server of a Windows named
pipe (which, in spite of what Unix programmers will infer from that
name, is actually closer to Windows's analogue of a Unix-domain
socket). Each one provides a fully featured Socket wrapper around the
hairy Windows named pipe API, so that the rest of the code base should
be able to use these interchangeably with ordinary sockets and hardly
notice the difference.

As part of this work, I've introduced a mechanism in winhandl.c to
permit it to store handles of event objects on behalf of other Windows
support modules and deal with passing them to applications' main event
loops as necessary. (Perhaps it would have been cleaner to split
winhandl.c into an event-object tracking layer analogous to uxsel, and
the handle management which is winhandl.c's proper job, but this is
less disruptive for the present.)

[originally from svn r10069]
2013-11-17 14:04:01 +00:00