nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 09:27:59 +00:00
Code Issues Projects Releases Wiki Activity
3c6ab5bbb7
putty-source/sftpserver.c

280 lines
7.7 KiB
C
Raw Normal View History

Add an SFTP server to the SSH server code. Unlike the traditional Unix SSH server organisation, the SFTP server is built into the same process as all the rest of the code. sesschan.c spots a subsystem request for "sftp", and responds to it by instantiating an SftpServer object and swapping out its own vtable for one that talks to it. (I rather like the idea of an object swapping its own vtable for a different one in the middle of its lifetime! This is one of those tricks that would be absurdly hard to implement in a 'proper' OO language, but when you're doing vtables by hand in C, it's no more difficult than any other piece of ordinary pointer manipulation. As long as the methods in both vtables expect the same physical structure layout, it doesn't cause a problem.) The SftpServer object doesn't deal directly with SFTP packet formats; it implements the SFTP server logic in a more abstract way, by having a vtable method for each SFTP request type with an appropriate parameter list. It sends its replies by calling methods in another vtable called SftpReplyBuilder, which in the normal case will write an SFTP reply packet to send back to the client. So SftpServer can focus more or less completely on the details of a particular filesystem API - and hence, the implementation I've got lives in the unix source directory, and works directly with file descriptors and struct stat and the like. (One purpose of this abstraction layer is that I may well want to write a second dummy implementation, for test-suite purposes, with completely controllable behaviour, and now I have a handy place to plug it in in place of the live filesystem.) In between sesschan's parsing of the byte stream into SFTP packets and the SftpServer object, there's a layer in the new file sftpserver.c which does the actual packet decoding and encoding: each request packet is passed to that, which pulls the fields out of the request packet and calls the appropriate method of SftpServer. It also provides the default SftpReplyBuilder which makes the output packet. I've moved some code out of the previous SFTP client implementation - basic packet construction code, and in particular the BinarySink/ BinarySource marshalling fuinction for fxp_attrs - into sftpcommon.c, so that the two directions can share as much as possible.
2018-10-20 21:10:32 +00:00
/*
* Implement the centralised parts of the server side of SFTP.
*/
#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include "putty.h"
#include "ssh.h"
#include "sftp.h"
struct sftp_packet *sftp_handle_request(
SftpServer *srv, struct sftp_packet *req)
{
struct sftp_packet *reply;
unsigned id;
Fix two accidental overwrites of 'flags'. When I came to actually remove the global 'flags' word, I found that I got compile failures in two functions that should never have been accessing it at all, because they forgot to declare _local_ variables of the same name. Yikes! (Of course, _now_ that's harmless, because I've just removed all the actual semantics from the global variable. But I'm about to remove the variable too, so these bugs would become compile failures.)
2020-01-30 06:40:21 +00:00
uint32_t flags;
Add an SFTP server to the SSH server code. Unlike the traditional Unix SSH server organisation, the SFTP server is built into the same process as all the rest of the code. sesschan.c spots a subsystem request for "sftp", and responds to it by instantiating an SftpServer object and swapping out its own vtable for one that talks to it. (I rather like the idea of an object swapping its own vtable for a different one in the middle of its lifetime! This is one of those tricks that would be absurdly hard to implement in a 'proper' OO language, but when you're doing vtables by hand in C, it's no more difficult than any other piece of ordinary pointer manipulation. As long as the methods in both vtables expect the same physical structure layout, it doesn't cause a problem.) The SftpServer object doesn't deal directly with SFTP packet formats; it implements the SFTP server logic in a more abstract way, by having a vtable method for each SFTP request type with an appropriate parameter list. It sends its replies by calling methods in another vtable called SftpReplyBuilder, which in the normal case will write an SFTP reply packet to send back to the client. So SftpServer can focus more or less completely on the details of a particular filesystem API - and hence, the implementation I've got lives in the unix source directory, and works directly with file descriptors and struct stat and the like. (One purpose of this abstraction layer is that I may well want to write a second dummy implementation, for test-suite purposes, with completely controllable behaviour, and now I have a handy place to plug it in in place of the live filesystem.) In between sesschan's parsing of the byte stream into SFTP packets and the SftpServer object, there's a layer in the new file sftpserver.c which does the actual packet decoding and encoding: each request packet is passed to that, which pulls the fields out of the request packet and calls the appropriate method of SftpServer. It also provides the default SftpReplyBuilder which makes the output packet. I've moved some code out of the previous SFTP client implementation - basic packet construction code, and in particular the BinarySink/ BinarySource marshalling fuinction for fxp_attrs - into sftpcommon.c, so that the two directions can share as much as possible.
2018-10-20 21:10:32 +00:00
ptrlen path, dstpath, handle, data;
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
uint64_t offset;
Add an SFTP server to the SSH server code. Unlike the traditional Unix SSH server organisation, the SFTP server is built into the same process as all the rest of the code. sesschan.c spots a subsystem request for "sftp", and responds to it by instantiating an SftpServer object and swapping out its own vtable for one that talks to it. (I rather like the idea of an object swapping its own vtable for a different one in the middle of its lifetime! This is one of those tricks that would be absurdly hard to implement in a 'proper' OO language, but when you're doing vtables by hand in C, it's no more difficult than any other piece of ordinary pointer manipulation. As long as the methods in both vtables expect the same physical structure layout, it doesn't cause a problem.) The SftpServer object doesn't deal directly with SFTP packet formats; it implements the SFTP server logic in a more abstract way, by having a vtable method for each SFTP request type with an appropriate parameter list. It sends its replies by calling methods in another vtable called SftpReplyBuilder, which in the normal case will write an SFTP reply packet to send back to the client. So SftpServer can focus more or less completely on the details of a particular filesystem API - and hence, the implementation I've got lives in the unix source directory, and works directly with file descriptors and struct stat and the like. (One purpose of this abstraction layer is that I may well want to write a second dummy implementation, for test-suite purposes, with completely controllable behaviour, and now I have a handy place to plug it in in place of the live filesystem.) In between sesschan's parsing of the byte stream into SFTP packets and the SftpServer object, there's a layer in the new file sftpserver.c which does the actual packet decoding and encoding: each request packet is passed to that, which pulls the fields out of the request packet and calls the appropriate method of SftpServer. It also provides the default SftpReplyBuilder which makes the output packet. I've moved some code out of the previous SFTP client implementation - basic packet construction code, and in particular the BinarySink/ BinarySource marshalling fuinction for fxp_attrs - into sftpcommon.c, so that the two directions can share as much as possible.
2018-10-20 21:10:32 +00:00
unsigned length;
struct fxp_attrs attrs;
DefaultSftpReplyBuilder dsrb;
SftpReplyBuilder *rb;
if (req->type == SSH_FXP_INIT) {
/*
* Special case which doesn't have a request id at the start.
*/
reply = sftp_pkt_init(SSH_FXP_VERSION);
/*
* Since we support only the lowest protocol version, we don't
* need to take the min of this and the client's version, or
* even to bother reading the client version number out of the
* input packet.
*/
put_uint32(reply, SFTP_PROTO_VERSION);
return reply;
}
/*
* Centralise the request id handling. We'll overwrite the type
* code of the output packet later.
*/
id = get_uint32(req);
reply = sftp_pkt_init(0);
put_uint32(reply, id);
dsrb.rb.vt = &DefaultSftpReplyBuilder_vt;
dsrb.pkt = reply;
rb = &dsrb.rb;
switch (req->type) {
case SSH_FXP_REALPATH:
path = get_string(req);
if (get_err(req))
goto decode_error;
sftpsrv_realpath(srv, rb, path);
break;
case SSH_FXP_OPEN:
path = get_string(req);
flags = get_uint32(req);
get_fxp_attrs(req, &attrs);
if (get_err(req))
goto decode_error;
if ((flags & (SSH_FXF_READ|SSH_FXF_WRITE)) == 0) {
fxp_reply_error(rb, SSH_FX_BAD_MESSAGE,
"open without READ or WRITE flag");
} else if ((flags & (SSH_FXF_CREAT|SSH_FXF_TRUNC)) == SSH_FXF_TRUNC) {
fxp_reply_error(rb, SSH_FX_BAD_MESSAGE,
"open with TRUNC but not CREAT");
} else if ((flags & (SSH_FXF_CREAT|SSH_FXF_EXCL)) == SSH_FXF_EXCL) {
fxp_reply_error(rb, SSH_FX_BAD_MESSAGE,
"open with EXCL but not CREAT");
} else {
sftpsrv_open(srv, rb, path, flags, attrs);
}
break;
case SSH_FXP_OPENDIR:
path = get_string(req);
if (get_err(req))
goto decode_error;
sftpsrv_opendir(srv, rb, path);
break;
case SSH_FXP_CLOSE:
handle = get_string(req);
if (get_err(req))
goto decode_error;
sftpsrv_close(srv, rb, handle);
break;
case SSH_FXP_MKDIR:
path = get_string(req);
get_fxp_attrs(req, &attrs);
if (get_err(req))
goto decode_error;
sftpsrv_mkdir(srv, rb, path, attrs);
break;
case SSH_FXP_RMDIR:
path = get_string(req);
if (get_err(req))
goto decode_error;
sftpsrv_rmdir(srv, rb, path);
break;
case SSH_FXP_REMOVE:
path = get_string(req);
if (get_err(req))
goto decode_error;
sftpsrv_remove(srv, rb, path);
break;
case SSH_FXP_RENAME:
path = get_string(req);
dstpath = get_string(req);
if (get_err(req))
goto decode_error;
sftpsrv_rename(srv, rb, path, dstpath);
break;
case SSH_FXP_STAT:
path = get_string(req);
if (get_err(req))
goto decode_error;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
sftpsrv_stat(srv, rb, path, true);
Add an SFTP server to the SSH server code. Unlike the traditional Unix SSH server organisation, the SFTP server is built into the same process as all the rest of the code. sesschan.c spots a subsystem request for "sftp", and responds to it by instantiating an SftpServer object and swapping out its own vtable for one that talks to it. (I rather like the idea of an object swapping its own vtable for a different one in the middle of its lifetime! This is one of those tricks that would be absurdly hard to implement in a 'proper' OO language, but when you're doing vtables by hand in C, it's no more difficult than any other piece of ordinary pointer manipulation. As long as the methods in both vtables expect the same physical structure layout, it doesn't cause a problem.) The SftpServer object doesn't deal directly with SFTP packet formats; it implements the SFTP server logic in a more abstract way, by having a vtable method for each SFTP request type with an appropriate parameter list. It sends its replies by calling methods in another vtable called SftpReplyBuilder, which in the normal case will write an SFTP reply packet to send back to the client. So SftpServer can focus more or less completely on the details of a particular filesystem API - and hence, the implementation I've got lives in the unix source directory, and works directly with file descriptors and struct stat and the like. (One purpose of this abstraction layer is that I may well want to write a second dummy implementation, for test-suite purposes, with completely controllable behaviour, and now I have a handy place to plug it in in place of the live filesystem.) In between sesschan's parsing of the byte stream into SFTP packets and the SftpServer object, there's a layer in the new file sftpserver.c which does the actual packet decoding and encoding: each request packet is passed to that, which pulls the fields out of the request packet and calls the appropriate method of SftpServer. It also provides the default SftpReplyBuilder which makes the output packet. I've moved some code out of the previous SFTP client implementation - basic packet construction code, and in particular the BinarySink/ BinarySource marshalling fuinction for fxp_attrs - into sftpcommon.c, so that the two directions can share as much as possible.
2018-10-20 21:10:32 +00:00
break;
case SSH_FXP_LSTAT:
path = get_string(req);
if (get_err(req))
goto decode_error;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
sftpsrv_stat(srv, rb, path, false);
Add an SFTP server to the SSH server code. Unlike the traditional Unix SSH server organisation, the SFTP server is built into the same process as all the rest of the code. sesschan.c spots a subsystem request for "sftp", and responds to it by instantiating an SftpServer object and swapping out its own vtable for one that talks to it. (I rather like the idea of an object swapping its own vtable for a different one in the middle of its lifetime! This is one of those tricks that would be absurdly hard to implement in a 'proper' OO language, but when you're doing vtables by hand in C, it's no more difficult than any other piece of ordinary pointer manipulation. As long as the methods in both vtables expect the same physical structure layout, it doesn't cause a problem.) The SftpServer object doesn't deal directly with SFTP packet formats; it implements the SFTP server logic in a more abstract way, by having a vtable method for each SFTP request type with an appropriate parameter list. It sends its replies by calling methods in another vtable called SftpReplyBuilder, which in the normal case will write an SFTP reply packet to send back to the client. So SftpServer can focus more or less completely on the details of a particular filesystem API - and hence, the implementation I've got lives in the unix source directory, and works directly with file descriptors and struct stat and the like. (One purpose of this abstraction layer is that I may well want to write a second dummy implementation, for test-suite purposes, with completely controllable behaviour, and now I have a handy place to plug it in in place of the live filesystem.) In between sesschan's parsing of the byte stream into SFTP packets and the SftpServer object, there's a layer in the new file sftpserver.c which does the actual packet decoding and encoding: each request packet is passed to that, which pulls the fields out of the request packet and calls the appropriate method of SftpServer. It also provides the default SftpReplyBuilder which makes the output packet. I've moved some code out of the previous SFTP client implementation - basic packet construction code, and in particular the BinarySink/ BinarySource marshalling fuinction for fxp_attrs - into sftpcommon.c, so that the two directions can share as much as possible.
2018-10-20 21:10:32 +00:00
break;
case SSH_FXP_FSTAT:
handle = get_string(req);
if (get_err(req))
goto decode_error;
sftpsrv_fstat(srv, rb, handle);
break;
case SSH_FXP_SETSTAT:
path = get_string(req);
get_fxp_attrs(req, &attrs);
if (get_err(req))
goto decode_error;
sftpsrv_setstat(srv, rb, path, attrs);
break;
case SSH_FXP_FSETSTAT:
handle = get_string(req);
get_fxp_attrs(req, &attrs);
if (get_err(req))
goto decode_error;
sftpsrv_fsetstat(srv, rb, handle, attrs);
break;
case SSH_FXP_READ:
handle = get_string(req);
offset = get_uint64(req);
length = get_uint32(req);
if (get_err(req))
goto decode_error;
sftpsrv_read(srv, rb, handle, offset, length);
break;
case SSH_FXP_READDIR:
handle = get_string(req);
if (get_err(req))
goto decode_error;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
sftpsrv_readdir(srv, rb, handle, INT_MAX, false);
Add an SFTP server to the SSH server code. Unlike the traditional Unix SSH server organisation, the SFTP server is built into the same process as all the rest of the code. sesschan.c spots a subsystem request for "sftp", and responds to it by instantiating an SftpServer object and swapping out its own vtable for one that talks to it. (I rather like the idea of an object swapping its own vtable for a different one in the middle of its lifetime! This is one of those tricks that would be absurdly hard to implement in a 'proper' OO language, but when you're doing vtables by hand in C, it's no more difficult than any other piece of ordinary pointer manipulation. As long as the methods in both vtables expect the same physical structure layout, it doesn't cause a problem.) The SftpServer object doesn't deal directly with SFTP packet formats; it implements the SFTP server logic in a more abstract way, by having a vtable method for each SFTP request type with an appropriate parameter list. It sends its replies by calling methods in another vtable called SftpReplyBuilder, which in the normal case will write an SFTP reply packet to send back to the client. So SftpServer can focus more or less completely on the details of a particular filesystem API - and hence, the implementation I've got lives in the unix source directory, and works directly with file descriptors and struct stat and the like. (One purpose of this abstraction layer is that I may well want to write a second dummy implementation, for test-suite purposes, with completely controllable behaviour, and now I have a handy place to plug it in in place of the live filesystem.) In between sesschan's parsing of the byte stream into SFTP packets and the SftpServer object, there's a layer in the new file sftpserver.c which does the actual packet decoding and encoding: each request packet is passed to that, which pulls the fields out of the request packet and calls the appropriate method of SftpServer. It also provides the default SftpReplyBuilder which makes the output packet. I've moved some code out of the previous SFTP client implementation - basic packet construction code, and in particular the BinarySink/ BinarySource marshalling fuinction for fxp_attrs - into sftpcommon.c, so that the two directions can share as much as possible.
2018-10-20 21:10:32 +00:00
break;
case SSH_FXP_WRITE:
handle = get_string(req);
offset = get_uint64(req);
data = get_string(req);
if (get_err(req))
goto decode_error;
sftpsrv_write(srv, rb, handle, offset, data);
break;
default:
if (get_err(req))
goto decode_error;
fxp_reply_error(rb, SSH_FX_OP_UNSUPPORTED,
"Unrecognised request type");
break;
decode_error:
fxp_reply_error(rb, SSH_FX_BAD_MESSAGE, "Unable to decode request");
}
return reply;
}
static void default_reply_ok(SftpReplyBuilder *reply)
{
DefaultSftpReplyBuilder *d =
container_of(reply, DefaultSftpReplyBuilder, rb);
d->pkt->type = SSH_FXP_STATUS;
put_uint32(d->pkt, SSH_FX_OK);
put_stringz(d->pkt, "");
}
static void default_reply_error(
SftpReplyBuilder *reply, unsigned code, const char *msg)
{
DefaultSftpReplyBuilder *d =
container_of(reply, DefaultSftpReplyBuilder, rb);
d->pkt->type = SSH_FXP_STATUS;
put_uint32(d->pkt, code);
put_stringz(d->pkt, msg);
}
static void default_reply_name_count(SftpReplyBuilder *reply, unsigned count)
{
DefaultSftpReplyBuilder *d =
container_of(reply, DefaultSftpReplyBuilder, rb);
d->pkt->type = SSH_FXP_NAME;
put_uint32(d->pkt, count);
}
static void default_reply_full_name(SftpReplyBuilder *reply, ptrlen name,
ptrlen longname, struct fxp_attrs attrs)
{
DefaultSftpReplyBuilder *d =
container_of(reply, DefaultSftpReplyBuilder, rb);
d->pkt->type = SSH_FXP_NAME;
put_stringpl(d->pkt, name);
put_stringpl(d->pkt, longname);
put_fxp_attrs(d->pkt, attrs);
}
static void default_reply_simple_name(SftpReplyBuilder *reply, ptrlen name)
{
fxp_reply_name_count(reply, 1);
fxp_reply_full_name(reply, name, PTRLEN_LITERAL(""), no_attrs);
}
static void default_reply_handle(SftpReplyBuilder *reply, ptrlen handle)
{
DefaultSftpReplyBuilder *d =
container_of(reply, DefaultSftpReplyBuilder, rb);
d->pkt->type = SSH_FXP_HANDLE;
put_stringpl(d->pkt, handle);
}
static void default_reply_data(SftpReplyBuilder *reply, ptrlen data)
{
DefaultSftpReplyBuilder *d =
container_of(reply, DefaultSftpReplyBuilder, rb);
d->pkt->type = SSH_FXP_DATA;
put_stringpl(d->pkt, data);
}
static void default_reply_attrs(
SftpReplyBuilder *reply, struct fxp_attrs attrs)
{
DefaultSftpReplyBuilder *d =
container_of(reply, DefaultSftpReplyBuilder, rb);
d->pkt->type = SSH_FXP_ATTRS;
put_fxp_attrs(d->pkt, attrs);
}
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
const SftpReplyBuilderVtable DefaultSftpReplyBuilder_vt = {
.reply_ok = default_reply_ok,
.reply_error = default_reply_error,
.reply_simple_name = default_reply_simple_name,
.reply_name_count = default_reply_name_count,
.reply_full_name = default_reply_full_name,
.reply_handle = default_reply_handle,
.reply_data = default_reply_data,
.reply_attrs = default_reply_attrs,
Add an SFTP server to the SSH server code. Unlike the traditional Unix SSH server organisation, the SFTP server is built into the same process as all the rest of the code. sesschan.c spots a subsystem request for "sftp", and responds to it by instantiating an SftpServer object and swapping out its own vtable for one that talks to it. (I rather like the idea of an object swapping its own vtable for a different one in the middle of its lifetime! This is one of those tricks that would be absurdly hard to implement in a 'proper' OO language, but when you're doing vtables by hand in C, it's no more difficult than any other piece of ordinary pointer manipulation. As long as the methods in both vtables expect the same physical structure layout, it doesn't cause a problem.) The SftpServer object doesn't deal directly with SFTP packet formats; it implements the SFTP server logic in a more abstract way, by having a vtable method for each SFTP request type with an appropriate parameter list. It sends its replies by calling methods in another vtable called SftpReplyBuilder, which in the normal case will write an SFTP reply packet to send back to the client. So SftpServer can focus more or less completely on the details of a particular filesystem API - and hence, the implementation I've got lives in the unix source directory, and works directly with file descriptors and struct stat and the like. (One purpose of this abstraction layer is that I may well want to write a second dummy implementation, for test-suite purposes, with completely controllable behaviour, and now I have a handy place to plug it in in place of the live filesystem.) In between sesschan's parsing of the byte stream into SFTP packets and the SftpServer object, there's a layer in the new file sftpserver.c which does the actual packet decoding and encoding: each request packet is passed to that, which pulls the fields out of the request packet and calls the appropriate method of SftpServer. It also provides the default SftpReplyBuilder which makes the output packet. I've moved some code out of the previous SFTP client implementation - basic packet construction code, and in particular the BinarySink/ BinarySource marshalling fuinction for fxp_attrs - into sftpcommon.c, so that the two directions can share as much as possible.
2018-10-20 21:10:32 +00:00
};
Reference in New Issue Copy Permalink