draft-ietf-secsh-filexfer-04.txt | draft-ietf-secsh-filexfer-05.txt | |||
---|---|---|---|---|
Secure Shell Working Group J. Galbraith | Secure Shell Working Group J. Galbraith | |||
Internet-Draft VanDyke Software | Internet-Draft VanDyke Software | |||
Expires: June 18, 2003 T. Ylonen | Expires: July 1, 2004 T. Ylonen | |||
S. Lehtinen | S. Lehtinen | |||
SSH Communications Security Corp | SSH Communications Security Corp | |||
December 18, 2002 | January 2004 | |||
SSH File Transfer Protocol | SSH File Transfer Protocol | |||
draft-ietf-secsh-filexfer-04.txt | draft-ietf-secsh-filexfer-05.txt | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that other | |||
other groups may also distribute working documents as | groups may also distribute working documents as Internet-Drafts. | |||
Internet-Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at http:// | The list of current Internet-Drafts can be accessed at http:// | |||
www.ietf.org/ietf/1id-abstracts.txt. | www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on June 18, 2003. | This Internet-Draft will expire on July 1, 2004. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2002). All Rights Reserved. | Copyright (C) The Internet Society (2004). All Rights Reserved. | |||
Abstract | Abstract | |||
The SSH File Transfer Protocol provides secure file transfer | The SSH File Transfer Protocol provides secure file transfer | |||
functionality over any reliable data stream. It is the standard file | functionality over any reliable data stream. It is the standard file | |||
transfer protocol for use with the SSH2 protocol. This document | transfer protocol for use with the SSH2 protocol. This document | |||
describes the file transfer protocol and its interface to the SSH2 | describes the file transfer protocol and its interface to the SSH2 | |||
protocol suite. | protocol suite. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Use with the SSH Connection Protocol . . . . . . . . . . . 4 | 2. Use with the SSH Connection Protocol . . . . . . . . . . . 5 | |||
3. General Packet Format . . . . . . . . . . . . . . . . . . 5 | 2.1 The Use of 'stderr' in the server . . . . . . . . . . . . 5 | |||
3.1 The use of stderr in the server . . . . . . . . . . . . . 6 | 3. General Packet Format . . . . . . . . . . . . . . . . . . 6 | |||
3.1 Packet Types . . . . . . . . . . . . . . . . . . . . . . . 6 | ||||
4. Protocol Initialization . . . . . . . . . . . . . . . . . 8 | 4. Protocol Initialization . . . . . . . . . . . . . . . . . 8 | |||
4.1 Client Initialization . . . . . . . . . . . . . . . . . . 8 | 4.1 Client Initialization . . . . . . . . . . . . . . . . . . 8 | |||
4.2 Server Initialization . . . . . . . . . . . . . . . . . . 8 | 4.2 Server Initialization . . . . . . . . . . . . . . . . . . 8 | |||
4.3 Determining Server Newline Convention . . . . . . . . . . 9 | 4.3 Determining Server Newline Convention . . . . . . . . . . 9 | |||
5. File Attributes . . . . . . . . . . . . . . . . . . . . . 10 | 4.4 Supported Features . . . . . . . . . . . . . . . . . . . . 9 | |||
5.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 5. File Attributes . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 5.1 valid-attribute-flags . . . . . . . . . . . . . . . . . . 12 | |||
5.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 5.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
5.4 Owner and Group . . . . . . . . . . . . . . . . . . . . . 11 | 5.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
5.5 Permissions . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.4 Owner and Group . . . . . . . . . . . . . . . . . . . . . 14 | |||
5.6 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.5 Permissions . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
5.7 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.6 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
5.8 Extended attributes . . . . . . . . . . . . . . . . . . . 14 | 5.7 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
6. Requests From the Client to the Server . . . . . . . . . . 15 | 5.8 attrib-bits . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
6.1 Request Synchronization and Reordering . . . . . . . . . . 15 | 5.9 Extended Attributes . . . . . . . . . . . . . . . . . . . 19 | |||
6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . 16 | 6. Requests From the Client to the Server . . . . . . . . . . 20 | |||
6.3 Opening, Creating, and Closing Files . . . . . . . . . . . 16 | 6.1 Request Synchronization and Reordering . . . . . . . . . . 20 | |||
6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . 19 | 6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
6.5 Removing and Renaming Files . . . . . . . . . . . . . . . 20 | 6.3 Opening and Closing Files and Directories . . . . . . . . 21 | |||
6.6 Creating and Deleting Directories . . . . . . . . . . . . 21 | 6.3.1 Opening a File . . . . . . . . . . . . . . . . . . . . . . 21 | |||
6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . 21 | 6.3.2 Opening a Directory . . . . . . . . . . . . . . . . . . . 25 | |||
6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . 22 | 6.3.3 Closing Handles . . . . . . . . . . . . . . . . . . . . . 26 | |||
6.9 Setting File Attributes . . . . . . . . . . . . . . . . . 23 | 6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . 26 | |||
6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . 24 | 6.4.1 Reading Files . . . . . . . . . . . . . . . . . . . . . . 26 | |||
6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . 25 | 6.4.2 Reading Directories . . . . . . . . . . . . . . . . . . . 27 | |||
6.11.1 Best practice for dealing with paths . . . . . . . . . . . 25 | 6.4.3 Writing Files . . . . . . . . . . . . . . . . . . . . . . 27 | |||
7. Responses from the Server to the Client . . . . . . . . . 26 | 6.5 Removing and Renaming Files . . . . . . . . . . . . . . . 28 | |||
8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . 30 | 6.6 Creating and Deleting Directories . . . . . . . . . . . . 29 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . 31 | 6.7 Retrieving File Attributes . . . . . . . . . . . . . . . . 30 | |||
10. Changes from previous protocol versions . . . . . . . . . 32 | 6.8 Setting File Attributes . . . . . . . . . . . . . . . . . 30 | |||
10.1 Changes between versions 4 and 3 . . . . . . . . . . . . . 32 | 6.9 Dealing with Symbolic Links . . . . . . . . . . . . . . . 31 | |||
10.2 Changes between versions 3 and 2 . . . . . . . . . . . . . 33 | 6.10 Canonicalizing the Server-Side Path Name . . . . . . . . . 32 | |||
10.3 Changes between versions 2 and 1 . . . . . . . . . . . . . 33 | 6.10.1 Best Practice for Dealing with Paths . . . . . . . . . . . 32 | |||
10.4 Changes between versions 1 and 0 . . . . . . . . . . . . . 33 | 7. Responses from the Server to the Client . . . . . . . . . 34 | |||
11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . 34 | 8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
References . . . . . . . . . . . . . . . . . . . . . . . . 35 | 8.1 Checking File Contents . . . . . . . . . . . . . . . . . . 40 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 35 | 9. Security Considerations . . . . . . . . . . . . . . . . . 42 | |||
Intellectual Property and Copyright Statements . . . . . . 37 | 10. Changes from Previous Protocol Versions . . . . . . . . . 43 | |||
10.1 Changes Between Versions 5 and 4 . . . . . . . . . . . . . 43 | ||||
10.2 Changes Between Versions 4 and 3 . . . . . . . . . . . . . 44 | ||||
10.3 Changes Between Versions 3 and 2 . . . . . . . . . . . . . 44 | ||||
10.4 Changes Between Versions 2 and 1 . . . . . . . . . . . . . 45 | ||||
10.5 Changes Between Versions 1 and 0 . . . . . . . . . . . . . 45 | ||||
11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . 46 | ||||
Normative References . . . . . . . . . . . . . . . . . . . 47 | ||||
Informative References . . . . . . . . . . . . . . . . . . 48 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48 | ||||
Intellectual Property and Copyright Statements . . . . . . 49 | ||||
1. Introduction | 1. Introduction | |||
This protocol provides secure file transfer (and more generally file | This protocol provides secure file transfer (and more generally file | |||
system access) functionality over a reliable data stream, such as a | system access.) It is designed so that it could be used to implement | |||
channel in the SSH2 protocol [5]. | a secure remote file system service, as well as a secure file | |||
transfer service. | ||||
This protocol is designed so that it could be used to implement a | ||||
secure remote file system service, as well as a secure file transfer | ||||
service. | ||||
This protocol assumes that it runs over a secure channel, and that | This protocol assumes that it runs over a secure channel, such as a | |||
the server has already authenticated the user at the client end, and | channel in the SSH2 protocol [3]. and that the server has already | |||
that the identity of the client user is externally available to the | authenticated the client, and that the identity of the client user is | |||
server implementation. | available to the protocol. | |||
In general, this protocol follows a simple request-response model. | In general, this protocol follows a simple request-response model. | |||
Each request and response contains a sequence number and multiple | Each request and response contains a sequence number and multiple | |||
requests may be pending simultaneously. There are a relatively large | requests may be pending simultaneously. There are a relatively large | |||
number of different request messages, but a small number of possible | number of different request messages, but a small number of possible | |||
response messages. Each request has one or more response messages | response messages. Each request has one or more response messages | |||
that may be returned in result (e.g., a read either returns data or | that may be returned in result (e.g., a read either returns data or | |||
reports error status). | reports error status). | |||
The packet format descriptions in this specification follow the | The packet format descriptions in this specification follow the | |||
notation presented in the secsh architecture draft. [5] | notation presented in the secsh architecture draft. [3] | |||
Even though this protocol is described in the context of the SSH2 | Even though this protocol is described in the context of the SSH2 | |||
protocol, this protocol is general and independent of the rest of the | protocol, this protocol is general and independent of the rest of the | |||
SSH2 protocol suite. It could be used in a number of different | SSH2 protocol suite. It could be used in a number of different | |||
applications, such as secure file transfer over TLS RFC 2246 [1] and | applications, such as secure file transfer over TLS RFC 2246 [6] and | |||
transfer of management information in VPN applications. | transfer of management information in VPN applications. | |||
2. Use with the SSH Connection Protocol | 2. Use with the SSH Connection Protocol | |||
When used with the SSH2 Protocol suite, this protocol is intended to | When used with the SSH2 Protocol suite, this protocol is intended to | |||
be used from the SSH Connection Protocol [7] as a subsystem, as | be used from the SSH Connection Protocol [5] as a subsystem, as | |||
described in section ``Starting a Shell or a Command''. The | described in section ''Starting a Shell or a Command''. The subsystem | |||
subsystem name used with this protocol is "sftp". | name used with this protocol is "sftp". | |||
2.1 The Use of 'stderr' in the server | ||||
This protocol uses stdout and stdin to transmit binary protocol data. | ||||
The "session" channel SSH Connection Protocol [5], which is used by | ||||
the subsystem, also supports the use of stderr. | ||||
Data sent on stderr by the server SHOULD be considered free format | ||||
debug or supplemental error information, and MAY be displayed to the | ||||
user. | ||||
For example, during initialization, there is no client request | ||||
active, so errors or warning information cannot be sent to the client | ||||
as part of the SFTP protocol at this early stage. However, the | ||||
errors or warnings MAY be sent as stderr text. | ||||
3. General Packet Format | 3. General Packet Format | |||
All packets transmitted over the secure connection are of the | All packets transmitted over the secure connection are of the | |||
following format: | following format: | |||
uint32 length | uint32 length | |||
byte type | byte type | |||
byte[length - 1] data payload | byte[length - 1] data payload | |||
That is, they are just data preceded by 32-bit length and 8-bit type | That is, they are data preceded by 32-bit length and 8-bit type | |||
fields. The `length' is the length of the data area, and does not | fields. The 'length' is the length of the data area, and does not | |||
include the `length' field itself. The format and interpretation of | include the 'length' field itself. The format and interpretation of | |||
the data area depends on the packet type. | the data area depends on the packet type. | |||
All packet descriptions below only specify the packet type and the | All packet descriptions specify the packet type and the data that | |||
data that goes into the data field. Thus, they should be prefixed by | goes into the data field. Thus, they should be prefixed by the | |||
the `length' and `type' fields. | 'length' fields. | |||
This document defines one data type in addition to those defined in | ||||
secsh architecture draft. [3] | ||||
int64 | ||||
Represents a 64-bit signed integer. Stored as eight bytes in the | ||||
order of decreasing significance (network byte order). | ||||
The maximum size of a packet is in practice determined by the client | The maximum size of a packet is in practice determined by the client | |||
(the maximum size of read or write requests that it sends, plus a few | (the maximum size of read or write requests that it sends, plus a few | |||
bytes of packet overhead). All servers SHOULD support packets of at | bytes of packet overhead). All servers SHOULD support packets of at | |||
least 34000 bytes (where the packet size refers to the full length, | least 34000 bytes (where the packet size refers to the full length, | |||
including the header above). This should allow for reads and writes | including the header above). This should allow for reads and writes | |||
of at most 32768 bytes. | of at most 32768 bytes. | |||
There is no limit on the number of outstanding (non-acknowledged) | There is no limit on the number of outstanding (non-acknowledged) | |||
requests that the client may send to the server. In practice this is | requests that the client may send to the server. In practice this is | |||
limited by the buffering available on the data stream and the queuing | limited by the buffering available on the data stream and the queuing | |||
performed by the server. If the server's queues are full, it should | performed by the server. If the server's queues are full, it should | |||
not read any more data from the stream, and flow control will prevent | not read any more data from the stream, and flow control will prevent | |||
the client from sending more requests. Note, however, that while | the client from sending more requests. Note, however, that while | |||
there is no restriction on the protocol level, the client's API may | there is no restriction on the protocol level, the client's API may | |||
provide a limit in order to prevent infinite queuing of outgoing | provide a limit in order to prevent infinite queuing of outgoing | |||
requests at the client. | requests at the client. | |||
3.1 Packet Types | ||||
The following values are defined for packet types. | The following values are defined for packet types. | |||
#define SSH_FXP_INIT 1 | #define SSH_FXP_INIT 1 | |||
#define SSH_FXP_VERSION 2 | #define SSH_FXP_VERSION 2 | |||
#define SSH_FXP_OPEN 3 | #define SSH_FXP_OPEN 3 | |||
#define SSH_FXP_CLOSE 4 | #define SSH_FXP_CLOSE 4 | |||
#define SSH_FXP_READ 5 | #define SSH_FXP_READ 5 | |||
#define SSH_FXP_WRITE 6 | #define SSH_FXP_WRITE 6 | |||
#define SSH_FXP_LSTAT 7 | #define SSH_FXP_LSTAT 7 | |||
#define SSH_FXP_FSTAT 8 | #define SSH_FXP_FSTAT 8 | |||
skipping to change at page 6, line 38 | skipping to change at page 7, line 38 | |||
#define SSH_FXP_DATA 103 | #define SSH_FXP_DATA 103 | |||
#define SSH_FXP_NAME 104 | #define SSH_FXP_NAME 104 | |||
#define SSH_FXP_ATTRS 105 | #define SSH_FXP_ATTRS 105 | |||
#define SSH_FXP_EXTENDED 200 | #define SSH_FXP_EXTENDED 200 | |||
#define SSH_FXP_EXTENDED_REPLY 201 | #define SSH_FXP_EXTENDED_REPLY 201 | |||
RESERVED_FOR_EXTENSIONS 210-255 | RESERVED_FOR_EXTENSIONS 210-255 | |||
Additional packet types should only be defined if the protocol | Additional packet types should only be defined if the protocol | |||
version number (see Section ``Protocol Initialization'') is | version number (see Section ''Protocol Initialization'') is | |||
incremented, and their use MUST be negotiated using the version | incremented, and their use MUST be negotiated using the version | |||
number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY | number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY | |||
packets can be used to implement vendor-specific extensions. See | packets can be used to implement extensions, which can be vendor | |||
Section ``Vendor-Specific-Extensions'' for more details. | specific. See Section ''Extensions'' for more details. | |||
3.1 The use of stderr in the server | ||||
Packets are sent and received on stdout and stdin. Data sent on | ||||
stderr by the server SHOULD be considered debug or supplemental error | ||||
information, and MAY be displayed to the user. | ||||
For example, during initialization, there is no client request | ||||
active, so errors or warning information cannot be sent to the client | ||||
as part of the SFTP protocol at this early stage. However, the | ||||
errors or warnings MAY be sent as stderr text. | ||||
4. Protocol Initialization | 4. Protocol Initialization | |||
When the file transfer protocol starts, the client first sends a | When the file transfer protocol starts, the client first sends a | |||
SSH_FXP_INIT (including its version number) packet to the server. | SSH_FXP_INIT (including its version number) packet to the server. The | |||
The server responds with a SSH_FXP_VERSION packet, supplying the | server responds with a SSH_FXP_VERSION packet, supplying the lowest | |||
lowest of its own and the client's version number. Both parties | of its own and the client's version number. Both parties should from | |||
should from then on adhere to particular version of the protocol. | then on adhere to particular version of the protocol. | |||
The version number of the protocol specified in this document is 4. | The version number of the protocol specified in this document is 5. | |||
The version number should be incremented for each incompatible | The version number should be incremented for each incompatible | |||
revision of this protocol. | revision of this protocol. | |||
4.1 Client Initialization | 4.1 Client Initialization | |||
The SSH_FXP_INIT packet (from client to server) has the following | The SSH_FXP_INIT packet (from client to server) has the following | |||
data: | data: | |||
uint32 version | uint32 version | |||
skipping to change at page 8, line 52 | skipping to change at page 8, line 52 | |||
'version' is the lower of the protocol version supported by the | 'version' is the lower of the protocol version supported by the | |||
server and the version number received from the client. | server and the version number received from the client. | |||
The extension data may be empty, or may be a sequence of | The extension data may be empty, or may be a sequence of | |||
string extension_name | string extension_name | |||
string extension_data | string extension_data | |||
pairs (both strings MUST always be present if one is, but the | pairs (both strings MUST always be present if one is, but the | |||
`extension_data' string may be of zero length). If present, these | 'extension_data' string may be of zero length). If present, these | |||
strings indicate extensions to the baseline protocol. The | strings indicate extensions to the baseline protocol. The | |||
`extension_name' field(s) identify the name of the extension. The | 'extension_name' field(s) identify the name of the extension. The | |||
name should be of the form "name@domain", where the domain is the DNS | name should be of the form "name@domain", where the domain is the DNS | |||
domain name of the organization defining the extension. Additional | domain name of the organization defining the extension. Additional | |||
names that are not of this format may be defined later by the IETF. | names that are not of this format may be defined later by the IETF. | |||
Implementations MUST silently ignore any extensions whose name they | Implementations MUST silently ignore any extensions whose name they | |||
do not recognize. | do not recognize. | |||
4.3 Determining Server Newline Convention | 4.3 Determining Server Newline Convention | |||
In order to correctly process text files in a cross platform | In order to correctly process text files in a cross platform | |||
compatible way, the newline convention must be converted from that of | compatible way, newline sequences must be converted between client | |||
the server to that of the client, or, during an upload, from that of | and server conventions. | |||
the client to that of the server. | ||||
Versions 3 and prior of this protocol made no provisions for | ||||
processing text files. Many clients implemented some sort of | ||||
conversion algorithm, but without either a 'canonical' on the wire | ||||
format or knowledge of the servers newline convention, correct | ||||
conversion was not always possible. | ||||
Starting with Version 4, the SSH_FXF_TEXT file open flag (Section | The SSH_FXF_TEXT file open flag (Section 6.3.1) makes it possible to | |||
6.3) makes it possible to request that the server translate a file to | request that the server translate a file to a 'canonical' wire | |||
a 'canonical' on the wire format. This format uses \r\n as the line | format. This format uses \r\n as the line separator. | |||
separator. | ||||
Servers for systems using multiple newline characters (for example, | Servers for systems using multiple newline characters (for example, | |||
Mac OS X or VMS) or systems using counted records, MUST translate to | Mac OS X or VMS) or systems using counted records, MUST translate to | |||
the canonical form. | the canonical form. | |||
However, to ease the burden of implementation on servers that use a | However, to ease the burden of implementation on servers that use a | |||
single, simple separator sequence, the following extension allows the | single, simple separator sequence, the following extension allows the | |||
canonical format to be changed. | canonical format to be changed. | |||
string "newline" | string "newline" | |||
string new-canonical-separator (usually "\r" or "\n" or "\r\n") | string new-canonical-separator (usually "\r" or "\n" or "\r\n") | |||
All clients MUST support this extension. | All clients MUST support this extension. | |||
When processing text files, clients SHOULD NOT translate any | When processing text files, clients SHOULD NOT translate any | |||
character or sequence that is not an exact match of the servers | character or sequence that is not an exact match of the server's | |||
newline separator. | newline separator. | |||
In particular, if the newline sequence being used is the canonical | In particular, if the newline sequence being used is the canonical | |||
"\r\n" sequence, a lone \r or a lone \n SHOULD be written through | "\r\n" sequence, a lone "\r" or a lone "\n" SHOULD be written through | |||
without change. | without change. | |||
4.4 Supported Features | ||||
The sftp protocol has grown to be very rich, and now supports a | ||||
number of features that may not be available on all servers. | ||||
When a server receives a request for a feature it cannot support, it | ||||
MUST return a SSH_FX_OP_UNSUPPORTED status code, unless otherwise | ||||
specified. In order to facilitate clients being able to use the | ||||
maximum available feature set, and yet not be overly burdened by | ||||
dealing with SSH_FX_OP_UNSUPPORTED status codes, the following | ||||
extension is introduced. | ||||
string "supported" | ||||
string supported-structure | ||||
uint32 supported-attribute-mask | ||||
uint32 supported-attribute-bits | ||||
uint32 supported-open-flags | ||||
uint32 supported-access-mask | ||||
uint32 max-read-size | ||||
string extension-names[0..n] | ||||
supported-attribute-mask | ||||
This mask MAY by applied to the 'File Attributes' | ||||
valid-attribute-flags field (Section 5.1) to ensure that no | ||||
unsupported attributes are present during a operation which writes | ||||
attributes. | ||||
supported-attribute-bits | ||||
This mask MAY by applied to the 'File Attributes' attrib-bits | ||||
field (Section 5.8) to ensure that no unsupported attrib-bits are | ||||
present during a operation which writes attributes. | ||||
supported-open-flags | ||||
The supported-open-flags mask MAY be applied to the SSH_FXP_OPEN | ||||
(Section 6.3.1) flags field. | ||||
supported-access-mask | ||||
The supported-access-mask mask MAY be applied to the SSH_FXP_OPEN | ||||
(Section 6.3.1) desired-access field or the ace-mask field of an | ||||
ACL. | ||||
max-read-size | ||||
This is the maximum read size that the server gaurantees to | ||||
complete. For example, certain embedded server implementations | ||||
only complete the first 4K of a read, even if there is additional | ||||
data to be read from the file. | ||||
If the server specifies a non-zero value, it MUST return at least | ||||
the max-read-size number of bytes for any read requesting | ||||
max-read-size bytes. Failure to return max-read-size bytes in | ||||
such a case indicates either EOF or another error condition | ||||
occurred. | ||||
extension names | ||||
The extension names may be empty (contains zero strings), or it | ||||
may contain any named extensions that the server wishes to | ||||
advertise. | ||||
The client must be able to differentiate between attribute | ||||
extensions (Section 5.9) and extended requests (Section 8) by the | ||||
extension name. | ||||
Naturally, if a given attribute field, attribute mask bit, open flag, | ||||
or extension is required for correct operation, the client MUST | ||||
either not allow the bit to be masked off, or MUST fail the operation | ||||
gracefully without sending the request to the server. | ||||
The client MAY send requests that are not supported by the server; | ||||
however, it is not normally expected to be productive to do so. The | ||||
client SHOULD apply the mask even to attrib structures received from | ||||
the server. The server MAY include attributes or attrib-bits that | ||||
are not included in the mask. Such attributes or attrib-bits are | ||||
effectively read-only. | ||||
5. File Attributes | 5. File Attributes | |||
A new compound data type is defined for encoding file attributes. | A new compound data type is defined for encoding file attributes. The | |||
The same encoding is used both when returning file attributes from | same encoding is used both when returning file attributes from the | |||
the server and when sending file attributes to the server. When | server and when sending file attributes to the server. | |||
sending it to the server, the flags field specifies which attributes | ||||
are included, and the server will use default values for the | ||||
remaining attributes (or will not modify the values of remaining | ||||
attributes). When receiving attributes from the server, the flags | ||||
specify which attributes are included in the returned data. The | ||||
server normally returns all attributes it knows about. | ||||
uint32 flags | uint32 valid-attribute-flags | |||
byte type always present | byte type always present | |||
uint64 size present only if flag SIZE | uint64 size present only if flag SIZE | |||
string owner present only if flag OWNERGROUP | string owner present only if flag OWNERGROUP | |||
string group present only if flag OWNERGROUP | string group present only if flag OWNERGROUP | |||
uint32 permissions present only if flag PERMISSIONS | uint32 permissions present only if flag PERMISSIONS | |||
uint64 atime present only if flag ACCESSTIME | int64 atime present only if flag ACCESSTIME | |||
uint32 atime_nseconds present only if flag SUBSECOND_TIMES | uint32 atime_nseconds present only if flag SUBSECOND_TIMES | |||
uint64 createtime present only if flag CREATETIME | int64 createtime present only if flag CREATETIME | |||
uint32 createtime_nseconds present only if flag SUBSECOND_TIMES | uint32 createtime_nseconds present only if flag SUBSECOND_TIMES | |||
uint64 mtime present only if flag MODIFYTIME | int64 mtime present only if flag MODIFYTIME | |||
uint32 mtime_nseconds present only if flag SUBSECOND_TIMES | uint32 mtime_nseconds present only if flag SUBSECOND_TIMES | |||
string acl present only if flag ACL | string acl present only if flag ACL | |||
uint32 attrib-bits present only if flag BITS | ||||
uint32 extended_count present only if flag EXTENDED | uint32 extended_count present only if flag EXTENDED | |||
string extended_type | string extended_type | |||
string extended_data | string extended_data | |||
... more extended data (extended_type - extended_data pairs), | ... more extended data (extended_type - extended_data pairs), | |||
so that number of pairs equals extended_count | so that number of pairs equals extended_count | |||
5.1 Flags | 5.1 valid-attribute-flags | |||
The `flags' specify which of the fields are present. Those fields | The 'valid-attribute-flags' specifies which of the fields are | |||
for which the corresponding flag is not set are not present (not | present. Those fields for which the corresponding flag is not set are | |||
included in the packet). New flags can only be added by incrementing | not present (not included in the packet). | |||
the protocol version number (or by using the extension mechanism | ||||
described below). | ||||
The flags bits are defined to have the following values: | The server generally includes all attributes it knows about; however, | |||
it may exclude attributes that are overly expensive to retrieve | ||||
unless the client explicitly requests them. | ||||
When writing attributes, the server SHOULD NOT modify attributes that | ||||
are not present in the structure. However, if necessary, the server | ||||
MAY use a default value for an absent attribute. | ||||
New fields can only be added by incrementing the protocol version | ||||
number (or by using the extension mechanism described below). | ||||
The following values are defined: | ||||
#define SSH_FILEXFER_ATTR_SIZE 0x00000001 | #define SSH_FILEXFER_ATTR_SIZE 0x00000001 | |||
#define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000040 | #define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004 | |||
#define SSH_FILEXFER_ATTR_ACCESSTIME 0x00000008 | #define SSH_FILEXFER_ATTR_ACCESSTIME 0x00000008 | |||
#define SSH_FILEXFER_ATTR_CREATETIME 0x00000010 | #define SSH_FILEXFER_ATTR_CREATETIME 0x00000010 | |||
#define SSH_FILEXFER_ATTR_MODIFYTIME 0x00000020 | #define SSH_FILEXFER_ATTR_MODIFYTIME 0x00000020 | |||
#define SSH_FILEXFER_ATTR_ACL 0x00000040 | #define SSH_FILEXFER_ATTR_ACL 0x00000040 | |||
#define SSH_FILEXFER_ATTR_OWNERGROUP 0x00000080 | #define SSH_FILEXFER_ATTR_OWNERGROUP 0x00000080 | |||
#define SSH_FILEXFER_ATTR_SUBSECOND_TIMES 0x00000100 | #define SSH_FILEXFER_ATTR_SUBSECOND_TIMES 0x00000100 | |||
#define SSH_FILEXFER_ATTR_BITS 0x00000200 | ||||
#define SSH_FILEXFER_ATTR_EXTENDED 0x80000000 | #define SSH_FILEXFER_ATTR_EXTENDED 0x80000000 | |||
In previous versions of this protocol flags value 0x00000002 was | 0x00000002 was used in a previous version of this protocol. It is | |||
SSH_FILEXFER_ATTR_UIDGID. This value is now unused, and OWNERGROUP | now a reserved value and MUST NOT appear in the mask. Some future | |||
was given a new value in order to ease implementation burden. | version of this protocol may reuse this value. | |||
0x00000002 MUST NOT appear in the mask. Some future version of this | ||||
protocol may reuse flag 0x00000002. | ||||
5.2 Type | 5.2 Type | |||
The type field is always present. The following types are defined: | The type field is always present. The following types are defined: | |||
#define SSH_FILEXFER_TYPE_REGULAR 1 | #define SSH_FILEXFER_TYPE_REGULAR 1 | |||
#define SSH_FILEXFER_TYPE_DIRECTORY 2 | #define SSH_FILEXFER_TYPE_DIRECTORY 2 | |||
#define SSH_FILEXFER_TYPE_SYMLINK 3 | #define SSH_FILEXFER_TYPE_SYMLINK 3 | |||
#define SSH_FILEXFER_TYPE_SPECIAL 4 | #define SSH_FILEXFER_TYPE_SPECIAL 4 | |||
#define SSH_FILEXFER_TYPE_UNKNOWN 5 | #define SSH_FILEXFER_TYPE_UNKNOWN 5 | |||
#define SSH_FILEXFER_TYPE_SOCKET 6 | ||||
#define SSH_FILEXFER_TYPE_CHAR_DEVICE 7 | ||||
#define SSH_FILEXFER_TYPE_BLOCK_DEVICE 8 | ||||
#define SSH_FILEXFER_TYPE_FIFO 9 | ||||
On a POSIX system, these values would be derived from the permission | On a POSIX system, these values would be derived from the mode field | |||
field. | of the stat structure. SPECIAL should be used for files that are of | |||
a known type which cannot be expressed in the protocol. UNKNOWN | ||||
should be used if the type is not known. | ||||
5.3 Size | 5.3 Size | |||
The `size' field specifies the size of the file on disk, in bytes. | The 'size' field specifies the size of the file on disk, in bytes. If | |||
If it is present during file creation, it should be considered a hint | it is present during file creation, it SHOULD be considered a hint as | |||
as to the files eventual size. | to the file's eventual size. | |||
If this field is present during a setstat operation, the file MUST be | ||||
extended or truncated to the specified size. Clients SHOULD | ||||
therefore be careful specifying size during a setstat operation. | ||||
Files opened with the SSH_FXF_TEXT flag may have a size that is | Files opened with the SSH_FXF_TEXT flag may have a size that is | |||
greater or less than the value of the size field. | greater or less than the value of the size field. | |||
5.4 Owner and Group | 5.4 Owner and Group | |||
The `owner' and `group' fields are represented as UTF-8 strings; this | The 'owner' and 'group' fields are represented as UTF-8 strings; this | |||
is the form used by NFS v4. See NFS version 4 Protocol. [3] The | is the form used by NFS v4. See NFS version 4 Protocol [1]. The | |||
following text is selected quotations from section 5.6. | following text is selected quotations from section 5.6. | |||
To avoid a representation that is tied to a particular underlying | To avoid a representation that is tied to a particular underlying | |||
implementation at the client or server, the use of UTF-8 strings has | implementation at the client or server, the use of UTF-8 strings has | |||
been chosen. The string should be of the form user@dns_domain". | been chosen. The string should be of the form user@dns_domain". This | |||
This will allow for a client and server that do not use the same | will allow for a client and server that do not use the same local | |||
local representation the ability to translate to a common syntax that | representation the ability to translate to a common syntax that can | |||
can be interpreted by both. In the case where there is no | be interpreted by both. In the case where there is no translation | |||
translation available to the client or server, the attribute value | available to the client or server, the attribute value must be | |||
must be constructed without the "@". Therefore, the absence of the @ | constructed without the "@". Therefore, the absence of the @ from | |||
from the owner or owner_group attribute signifies that no translation | the owner or owner_group attribute signifies that no translation was | |||
was available and the receiver of the attribute should not place any | available and the receiver of the attribute should not place any | |||
special meaning with the attribute value. Even though the attribute | special meaning with the attribute value. Even though the attribute | |||
value can not be translated, it may still be useful. In the case of | value cannot be translated, it may still be useful. In the case of a | |||
a client, the attribute string may be used for local display of | client, the attribute string may be used for local display of | |||
ownership. | ownership. | |||
user@localhost represents a user in the context of the server. | ||||
If either the owner or group field is zero length, the field should | ||||
be considered absent, and no change should be made to that specific | ||||
field. | ||||
5.5 Permissions | 5.5 Permissions | |||
The `permissions' field contains a bit mask of file permissions as | The 'permissions' field contains a bit mask specifying file | |||
defined by POSIX [1]. | permissions. These permissions correspond to the st_mode field of | |||
the stat structure defined by POSIX [2]. | ||||
This protocol uses the following values for the symbols declared in | ||||
the posix standard. | ||||
#define S_IRUSR 0000400 (octal) | ||||
#define S_IWUSR 0000200 | ||||
#define S_IXUSR 0000100 | ||||
#define S_IRGRP 0000040 | ||||
#define S_IWGRP 0000020 | ||||
#define S_IXGRP 0000010 | ||||
#define S_IROTH 0000004 | ||||
#define S_IWOTH 0000002 | ||||
#define S_IXOTH 0000001 | ||||
#define S_ISUID 0004000 | ||||
#define S_ISGID 0002000 | ||||
#define S_ISVTX 0001000 | ||||
Implementations MUST NOT send bits that are not defined. | ||||
5.6 Times | 5.6 Times | |||
The 'atime', 'createtime', and 'mtime' contain the access, creation, | The 'atime', 'createtime', and 'mtime' contain the accesses, | |||
and modification times of the files, respectively. They are | creation, and modification times of the files, respectively. They | |||
represented as seconds from Jan 1, 1970 in UTC. | are represented as seconds from Jan 1, 1970 in UTC. | |||
A negative value indicates number of seconds before Jan 1, 1970. In | A negative value indicates number of seconds before Jan 1, 1970. In | |||
both cases, if the SSH_FILEXFER_ATTR_SUBSECOND_TIMES flag is set, the | both cases, if the SSH_FILEXFER_ATTR_SUBSECOND_TIMES flag is set, the | |||
nseconds field is to be added to the seconds field for the final time | nseconds field is to be added to the seconds field for the final time | |||
representation. For example, if the time to be represented is | representation. For example, if the time to be represented is | |||
one-half second before 0 hour January 1, 1970, the seconds field | one-half second before 0 hour January 1, 1970, the seconds field | |||
would have a value of negative one (-1) and the nseconds fields would | would have a value of negative one (-1) and the nseconds fields would | |||
have a value of one-half second (500000000). Values greater than | have a value of one-half second (500000000). Values greater than | |||
999,999,999 for nseconds are considered invalid. | 999,999,999 for nseconds are considered invalid. | |||
5.7 ACL | 5.7 ACL | |||
The 'ACL' field contains an ACL similar to that defined in section | The 'ACL' field contains an ACL similar to that defined in section | |||
5.9 of NFS version 4 Protocol [3]. | 5.9 of NFS version 4 Protocol [1]. | |||
uint32 ace-count | uint32 ace-count | |||
repeated ace-count time: | repeated ace-count time: | |||
uint32 ace-type | uint32 ace-type | |||
uint32 ace-flag | uint32 ace-flag | |||
uint32 ace-mask | uint32 ace-mask | |||
string who [UTF-8] | string who [UTF-8] | |||
ace-type is one of the following four values (taken from NFS Version | ace-type is one of the following four values (taken from NFS Version | |||
4 Protocol [3]: | 4 Protocol [1]: | |||
const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; | #define ACE4_ACCESS_ALLOWED_ACE_TYPE 0x00000000; | |||
const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001; | #define ACE4_ACCESS_DENIED_ACE_TYPE 0x00000001; | |||
const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002; | #define ACE4_SYSTEM_AUDIT_ACE_TYPE 0x00000002; | |||
const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003; | #define ACE4_SYSTEM_ALARM_ACE_TYPE 0x00000003; | |||
ace-flag is a combination of the following flag values. See NFS | ace-flag is a combination of the following flag values. See NFS | |||
Version 4 Protocol [3] section 5.9.2: | Version 4 Protocol [1] section 5.9.2: | |||
const ACE4_FILE_INHERIT_ACE = 0x00000001; | ||||
const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002; | ||||
const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004; | ||||
const ACE4_INHERIT_ONLY_ACE = 0x00000008; | ||||
const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010; | ||||
const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020; | ||||
const ACE4_IDENTIFIER_GROUP = 0x00000040; | ||||
#define ACE4_FILE_INHERIT_ACE 0x00000001; | ||||
#define ACE4_DIRECTORY_INHERIT_ACE 0x00000002; | ||||
#define ACE4_NO_PROPAGATE_INHERIT_ACE 0x00000004; | ||||
#define ACE4_INHERIT_ONLY_ACE 0x00000008; | ||||
#define ACE4_SUCCESSFUL_ACCESS_ACE_FLAG 0x00000010; | ||||
#define ACE4_FAILED_ACCESS_ACE_FLAG 0x00000020; | ||||
#define ACE4_IDENTIFIER_GROUP 0x00000040; | ||||
ace-mask is any combination of the following flags (taken from NFS | ace-mask is any combination of the following flags (taken from NFS | |||
Version 4 Protocol [3] section 5.9.3: | Version 4 Protocol [1] section 5.9.3: | |||
const ACE4_READ_DATA = 0x00000001; | #define ACE4_READ_DATA 0x00000001; | |||
const ACE4_LIST_DIRECTORY = 0x00000001; | #define ACE4_LIST_DIRECTORY 0x00000001; | |||
const ACE4_WRITE_DATA = 0x00000002; | #define ACE4_WRITE_DATA 0x00000002; | |||
const ACE4_ADD_FILE = 0x00000002; | #define ACE4_ADD_FILE 0x00000002; | |||
const ACE4_APPEND_DATA = 0x00000004; | #define ACE4_APPEND_DATA 0x00000004; | |||
const ACE4_ADD_SUBDIRECTORY = 0x00000004; | #define ACE4_ADD_SUBDIRECTORY 0x00000004; | |||
const ACE4_READ_NAMED_ATTRS = 0x00000008; | #define ACE4_READ_NAMED_ATTRS 0x00000008; | |||
const ACE4_WRITE_NAMED_ATTRS = 0x00000010; | #define ACE4_WRITE_NAMED_ATTRS 0x00000010; | |||
const ACE4_EXECUTE = 0x00000020; | #define ACE4_EXECUTE 0x00000020; | |||
const ACE4_DELETE_CHILD = 0x00000040; | #define ACE4_DELETE_CHILD 0x00000040; | |||
const ACE4_READ_ATTRIBUTES = 0x00000080; | #define ACE4_READ_ATTRIBUTES 0x00000080; | |||
const ACE4_WRITE_ATTRIBUTES = 0x00000100; | #define ACE4_WRITE_ATTRIBUTES 0x00000100; | |||
const ACE4_DELETE = 0x00010000; | #define ACE4_DELETE 0x00010000; | |||
const ACE4_READ_ACL = 0x00020000; | #define ACE4_READ_ACL 0x00020000; | |||
const ACE4_WRITE_ACL = 0x00040000; | #define ACE4_WRITE_ACL 0x00040000; | |||
const ACE4_WRITE_OWNER = 0x00080000; | #define ACE4_WRITE_OWNER 0x00080000; | |||
const ACE4_SYNCHRONIZE = 0x00100000; | #define ACE4_SYNCHRONIZE 0x00100000; | |||
who is a UTF-8 string of the form described in 'Owner and Group' | who is a UTF-8 string of the form described in 'Owner and Group' | |||
(Section 5.4) | (Section 5.4) | |||
Also, as per '5.9.4 ACE who' [3] there are several identifiers that | Also, as per '5.9.4 ACE who' [1] there are several identifiers that | |||
need to be understood universally. Some of these identifiers cannot | need to be understood universally. Some of these identifiers cannot | |||
be understood when an client access the server, but have meaning when | be understood when an client access the server, but have meaning when | |||
a local process accesses the file. The ability to display and modify | a local process accesses the file. The ability to display and modify | |||
these permissions is permitted over SFTP. | these permissions is permitted over SFTP. | |||
OWNER The owner of the file. | OWNER The owner of the file. | |||
GROUP The group associated with the file. | GROUP The group associated with the file. | |||
EVERYONE The world. | EVERYONE The world. | |||
skipping to change at page 14, line 24 | skipping to change at page 17, line 8 | |||
BATCH Accessed from a batch job. | BATCH Accessed from a batch job. | |||
ANONYMOUS Accessed without any authentication. | ANONYMOUS Accessed without any authentication. | |||
AUTHENTICATED Any authenticated user (opposite of ANONYMOUS). | AUTHENTICATED Any authenticated user (opposite of ANONYMOUS). | |||
SERVICE Access from a system service. | SERVICE Access from a system service. | |||
To avoid conflict, these special identifiers are distinguish by an | To avoid conflict, these special identifiers are distinguish by an | |||
appended "@" and should appear in the form "xxxx@" (note: no domain | appended "@". For example: ANONYMOUS@. | |||
name after the "@"). For example: ANONYMOUS@. | ||||
5.8 Extended attributes | 5.8 attrib-bits | |||
These bits reflect various attributes of the file or directory on the | ||||
server. | ||||
The following attrib-bits are defined: | ||||
#define SSH_FILEXFER_ATTR_FLAGS_READONLY 0x00000001 | ||||
#define SSH_FILEXFER_ATTR_FLAGS_SYSTEM 0x00000002 | ||||
#define SSH_FILEXFER_ATTR_FLAGS_HIDDEN 0x00000004 | ||||
#define SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE 0x00000008 | ||||
#define SSH_FILEXFER_ATTR_FLAGS_ARCHIVE 0x00000010 | ||||
#define SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED 0x00000020 | ||||
#define SSH_FILEXFER_ATTR_FLAGS_COMPRESSED 0x00000040 | ||||
#define SSH_FILEXFER_ATTR_FLAGS_SPARSE 0x00000080 | ||||
#define SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY 0x00000100 | ||||
#define SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE 0x00000200 | ||||
#define SSH_FILEXFER_ATTR_FLAGS_SYNC 0x00000400 | ||||
SSH_FILEXFER_ATTR_FLAGS_READONLY | ||||
Advisory, read-only bit. This bit is not part of the access | ||||
control information on the file, but is rather an advisory field | ||||
indicating that the file should not be written. | ||||
SSH_FILEXFER_ATTR_FLAGS_SYSTEM | ||||
The file is part of operating system. | ||||
SSH_FILEXFER_ATTR_FLAGS_HIDDEN | ||||
File SHOULD NOT be shown to user unless specifically requested. | ||||
For example, most UNIX systems SHOULD set this bit if the filename | ||||
begins with a 'period'. This bit may be read-only (Section 4.4). | ||||
Most UNIX systems will not allow this to be changed. | ||||
SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE | ||||
This attribute can only apply to directories. This attribute is | ||||
always read-only, and cannot be modified. This attribute means | ||||
that files and directory names in this directory should be | ||||
compared without regard to case. | ||||
It is recommended that where possible, the server's filesystem be | ||||
allowed to do comparisons. For example, if a client wished to | ||||
prompt a user before overwriting a file, it should not compare the | ||||
new name with the previously retrieved list of names in the | ||||
directory. Rather, it should first try to create the new file by | ||||
specifying SSH_FXF_CREATE_NEW flag. Then, if this fails and | ||||
returns SSH_FX_FILE_ALREADY_EXISTS, it should prompt the user and | ||||
then retry the create specifying SSH_FXF_CREATE_TRUNCATE. | ||||
Unless otherwise specified, filenames are assumed to be case | ||||
sensitive. | ||||
SSH_FILEXFER_ATTR_FLAGS_ARCHIVE | ||||
The file should be included in backup / archive operations. | ||||
SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED | ||||
The file is encrypted. | ||||
SSH_FILEXFER_ATTR_FLAGS_COMPRESSED | ||||
The file is compressed. | ||||
SSH_FILEXFER_ATTR_FLAGS_SPARSE | ||||
The file is a sparse file; this means that file blocks that have | ||||
not been explicitly written are not stored on disk. For example, | ||||
if a client writes a buffer at 10 M from the beginning of the | ||||
file, the blocks between the previous EOF marker and the 10 M | ||||
offset would not consume physical disk space. | ||||
Some server may store all files as sparse files, in which case | ||||
this bit will be unconditionally set. Other servers may not have | ||||
a mechanism for determining if the file is sparse, and so the file | ||||
MAY be stored sparse even if this flag is not set. | ||||
SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY | ||||
The file can only be opened for writing in append mode. | ||||
SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE | ||||
The file cannot be deleted or renamed, no hard link can be created | ||||
to this file and no data can be written to the file. | ||||
This bit implies a stronger level of protection than | ||||
SSH_FILEXFER_ATTR_FLAGS_READONLY, the file permission mask or | ||||
ACLs. Typically even the superuser cannot write to immutable | ||||
files, and only the superuser can set or remove the bit. | ||||
SSH_FILEXFER_ATTR_FLAGS_SYNC | ||||
When the file is modified, the changes are written synchronously | ||||
to the disk. | ||||
5.9 Extended Attributes | ||||
The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension | The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension | |||
mechanism for vendor-specific extensions. If the flag is specified, | mechanism for the attrib structure. If the flag is specified, then | |||
then the `extended_count' field is present. It specifies the number | the 'extended_count' field is present. It specifies the number of | |||
of extended_type-extended_data pairs that follow. Each of these | extended_type-extended_data pairs that follow. Each of these pairs | |||
pairs specifies an extended attribute. For each of the attributes, | specifies an extended attribute. For each of the attributes, the | |||
the extended_type field should be a string of the format | extended_type field should be a string of the format "name@domain", | |||
"name@domain", where "domain" is a valid, registered domain name and | where "domain" is a valid, registered domain name and "name" | |||
"name" identifies the method. The IETF may later standardize certain | identifies the method. The IETF may later standardize certain names | |||
names that deviate from this format (e.g., that do not contain the | that deviate from this format (e.g., that do not contain the "@" | |||
"@" sign). The interpretation of `extended_data' depends on the | sign). The interpretation of 'extended_data' depends on the type. | |||
type. Implementations SHOULD ignore extended data fields that they | Implementations SHOULD ignore extended data fields that they do not | |||
do not understand. | understand. | |||
Additional fields can be added to the attributes by either defining | Additional fields can be added to the attributes by either defining | |||
additional bits to the flags field to indicate their presence, or by | additional bits to the flags field to indicate their presence, or by | |||
defining extended attributes for them. The extended attributes | defining extended attributes for them. The extended attributes | |||
mechanism is recommended for most purposes; additional flags bits | mechanism is recommended for most purposes; additional flags bits | |||
should only be defined by an IETF standards action that also | should only be defined by an IETF standards action that also | |||
increments the protocol version number. The use of such new fields | increments the protocol version number. The use of such new fields | |||
MUST be negotiated by the version number in the protocol exchange. | MUST be negotiated by the version number in the protocol exchange. | |||
It is a protocol error if a packet with unsupported protocol bits is | It is a protocol error if a packet with unsupported protocol bits is | |||
received. | received. | |||
6. Requests From the Client to the Server | 6. Requests From the Client to the Server | |||
Requests from the client to the server represent the various file | Requests from the client to the server represent the various file | |||
system operations. Each request begins with an `id' field, which is | system operations. Each request begins with an 'request-id' field, | |||
a 32-bit identifier identifying the request (selected by the client). | which is a 32-bit identifier identifying the request (selected by the | |||
The same identifier will be returned in the response to the request. | client). The same identifier will be returned in the response to the | |||
One possible implementation is a monotonically increasing request | request. One possible implementation is a monotonically increasing | |||
sequence number (modulo 2^32). | request sequence number (modulo 2^32). | |||
Many operations in the protocol operate on open files. The | ||||
SSH_FXP_OPEN request can return a file handle (which is an opaque | ||||
variable-length string) which may be used to access the file later | ||||
(e.g. in a read operation). The client MUST NOT send requests the | ||||
server with bogus or closed handles. However, the server MUST | ||||
perform adequate checks on the handle in order to avoid security | ||||
risks due to fabricated handles. | ||||
This design allows either stateful and stateless server | ||||
implementation, as well as an implementation which caches state | ||||
between requests but may also flush it. The contents of the file | ||||
handle string are entirely up to the server and its design. The | ||||
client should not modify or attempt to interpret the file handle | ||||
strings. | ||||
The file handle strings MUST NOT be longer than 256 bytes. | ||||
6.1 Request Synchronization and Reordering | 6.1 Request Synchronization and Reordering | |||
The protocol and implementations MUST process requests relating to | The protocol and implementations MUST process requests relating to | |||
the same file in the order in which they are received. In other | the same file in the order in which they are received. In other | |||
words, if an application submits multiple requests to the server, the | words, if an application submits multiple requests to the server, the | |||
results in the responses will be the same as if it had sent the | results in the responses will be the same as if it had sent the | |||
requests one at a time and waited for the response in each case. For | requests one at a time and waited for the response in each case. For | |||
example, the server may process non-overlapping read/write requests | example, the server may process non-overlapping read/write requests | |||
to the same file in parallel, but overlapping reads and writes cannot | to the same file in parallel, but overlapping reads and writes cannot | |||
skipping to change at page 16, line 33 | skipping to change at page 21, line 14 | |||
An empty path name is valid, and it refers to the user's default | An empty path name is valid, and it refers to the user's default | |||
directory (usually the user's home directory). | directory (usually the user's home directory). | |||
Otherwise, no syntax is defined for file names by this specification. | Otherwise, no syntax is defined for file names by this specification. | |||
Clients should not make any other assumptions; however, they can | Clients should not make any other assumptions; however, they can | |||
splice path name components returned by SSH_FXP_READDIR together | splice path name components returned by SSH_FXP_READDIR together | |||
using a slash ('/') as the separator, and that will work as expected. | using a slash ('/') as the separator, and that will work as expected. | |||
In order to comply with IETF Policy on Character Sets and Languages | In order to comply with IETF Policy on Character Sets and Languages | |||
[2], all filenames are to be encoded in UTF-8. The shortest valid | [7], all filenames MUST be encoded in UTF-8. The shortest valid UTF-8 | |||
UTF-8 encoding of the UNICODE data MUST be used. The server is | encoding of the UNICODE data MUST be used. The server is responsible | |||
responsible for converting the UNICODE data to whatever canonical | for converting the UNICODE data to whatever canonical form it | |||
form it requires. | requires. | |||
For example, if the server requires that precomposed characters | For example, if the server requires that precomposed characters | |||
always be used, the server MUST NOT assume the filename as sent by | always be used, the server MUST NOT assume the filename as sent by | |||
the client has this attribute, but must do this normalization itself. | the client has this attribute, but must do this normalization itself. | |||
It is understood that the lack of well-defined semantics for file | It is understood that the lack of well-defined semantics for file | |||
names may cause interoperability problems between clients and servers | names may cause interoperability problems between clients and servers | |||
using radically different operating systems. However, this approach | using radically different operating systems. However, this approach | |||
is known to work acceptably with most systems, and alternative | is known to work acceptably with most systems, and alternative | |||
approaches that e.g. treat file names as sequences of structured | approaches that e.g. treat file names as sequences of structured | |||
components are quite complicated. | components are quite complicated. | |||
6.3 Opening, Creating, and Closing Files | 6.3 Opening and Closing Files and Directories | |||
Files are opened and created using the SSH_FXP_OPEN message, whose | Many operations in the protocol operate on open files. The | |||
data part is as follows: | SSH_FXP_OPEN and SSH_FXP_OPENDIR requests return a handle (which is | |||
an opaque, variable-length string) which may be used to access the | ||||
file or directory later. The client MUST NOT send requests the | ||||
server with bogus or closed handles. However, the server MUST | ||||
perform adequate checks on the handle in order to avoid security | ||||
risks due to fabricated handles. | ||||
uint32 id | This design allows either stateful and stateless server | |||
implementation, as well as an implementation which caches state | ||||
between requests but may also flush it. The contents of the file | ||||
handle string are entirely up to the server and its design. The | ||||
client should not modify or attempt to interpret the file handle | ||||
strings. | ||||
The file handle strings MUST NOT be longer than 256 bytes. | ||||
6.3.1 Opening a File | ||||
Files are opened and created using the SSH_FXP_OPEN message: | ||||
byte SSH_FXP_OPEN | ||||
uint32 request-id | ||||
string filename [UTF-8] | string filename [UTF-8] | |||
uint32 pflags | uint32 desired-access | |||
uint32 flags | ||||
ATTRS attrs | ATTRS attrs | |||
The `id' field is the request identifier as for all requests. | The response to this message will be either SSH_FXP_HANDLE (if the | |||
operation is successful) or SSH_FXP_STATUS (if the operation fails). | ||||
The `filename' field specifies the file name. See Section ``File | The 'request-id' field is the request identifier as for all requests. | |||
The 'filename' field specifies the file name. See Section ''File | ||||
Names'' for more information. | Names'' for more information. | |||
The `pflags' field is a bitmask. The following bits have been | The 'desired-access' field is a bitmask containing a combination of | |||
defined. | values from the ace-mask flags from section 5.7. | |||
#define SSH_FXF_READ 0x00000001 | The 'flags' field controls various aspects of the operation, | |||
#define SSH_FXF_WRITE 0x00000002 | including whether or not the file is created and the kind of locking | |||
#define SSH_FXF_APPEND 0x00000004 | desired. | |||
#define SSH_FXF_CREAT 0x00000008 | ||||
#define SSH_FXF_TRUNC 0x00000010 | ||||
#define SSH_FXF_EXCL 0x00000020 | ||||
#define SSH_FXF_TEXT 0x00000040 | ||||
These have the following meanings: | The following 'flags' are defined: | |||
SSH_FXF_READ | SSH_FXF_ACCESS_DISPOSITION = 0x00000007 | |||
Open the file for reading. | SSH_FXF_CREATE_NEW = 0x00000000 | |||
SSH_FXF_CREATE_TRUNCATE = 0x00000001 | ||||
SSH_FXF_OPEN_EXISTING = 0x00000002 | ||||
SSH_FXF_OPEN_OR_CREATE = 0x00000003 | ||||
SSH_FXF_TRUNCATE_EXISTING = 0x00000004 | ||||
SSH_FXF_ACCESS_APPEND_DATA = 0x00000008 | ||||
SSH_FXF_ACCESS_APPEND_DATA_ATOMIC = 0x00000010 | ||||
SSH_FXF_ACCESS_TEXT_MODE = 0x00000020 | ||||
SSH_FXF_ACCESS_READ_LOCK = 0x00000040 | ||||
SSH_FXF_ACCESS_WRITE_LOCK = 0x00000080 | ||||
SSH_FXF_ACCESS_DELETE_LOCK = 0x00000100 | ||||
SSH_FXF_WRITE | SSH_FXF_ACCESS_DISPOSITION | |||
Open the file for writing. If both this and SSH_FXF_READ are | Disposition is a 3 bit field that controls how the file is opened. | |||
specified, the file is opened for both reading and writing. | The server MUST support these bits. Any one of the following | |||
enumeration is allowed: | ||||
SSH_FXF_APPEND | SSH_FXF_CREATE_NEW | |||
Force all writes to append data at the end of the file. The | A new file is created; if the file already exists, the server | |||
offset parameter to write will be ignored. | MUST return status SSH_FX_FILE_ALREADY_EXISTS. | |||
SSH_FXF_CREAT | SSH_FXF_CREATE_TRUNCATE | |||
If this flag is specified, then a new file will be created if one | A new file is create; if the file already exists, it is | |||
does not already exist (if O_TRUNC is specified, the new file will | truncated. | |||
be truncated to zero length if it previously exists). | ||||
SSH_FXF_TRUNC | SSH_FXF_OPEN_EXISTING | |||
Forces an existing file with the same name to be truncated to zero | An existing file is opened. If the file does not exist, the | |||
length when creating a file by specifying SSH_FXF_CREAT. | server MUST return SSH_FX_NO_SUCH_FILE. If a directory in the | |||
SSH_FXF_CREAT MUST also be specified if this flag is used. | path does not exist, the server SHOULD return | |||
SSH_FX_NO_SUCH_PATH. It is also acceptable if the server | ||||
returns SSH_FX_NO_SUCH_FILE in this case. | ||||
SSH_FXF_EXCL | SSH_FXF_OPEN_OR_CREATE | |||
Causes the request to fail if the named file already exists. | If the file exists, it is opened. If the file does not exist, | |||
SSH_FXF_CREAT MUST also be specified if this flag is used. | it is created. | |||
SSH_FXF_TRUNCATE_EXISTING | ||||
An existing file is opened and truncated. If the file does not | ||||
exist, the server MUST return the same error codes as defined | ||||
for SSH_FXF_OPEN_EXISTING. | ||||
SSH_FXF_ACCESS_APPEND_DATA | ||||
Data is always written at the end of the file. The offset field | ||||
of the SSH_FXP_WRITE requests are ignored. | ||||
Data is not required to be appended atomically. This means that | ||||
if multiple writers attempt to append data simultaneously, data | ||||
from the first may be lost. However, data MAY be appended | ||||
atomically. | ||||
SSH_FXF_ACCESS_APPEND_DATA_ATOMIC | ||||
Data is always written at the end of the file. The offset field | ||||
of the SSH_FXP_WRITE requests are ignored. | ||||
Date MUST be written atomically so that there is no chance that | ||||
multiple appenders can collide and result in data being lost. | ||||
If both append flags are specified, the server SHOULD use atomic | ||||
append if it is available, but SHOULD use non-atomic appends | ||||
otherwise. The server SHOULD NOT fail the request in this case. | ||||
SSH_FXF_TEXT | SSH_FXF_TEXT | |||
Indicates that the server should treat the file as text and | Indicates that the server should treat the file as text and | |||
convert it to the canonical newline convention in use. (See | convert it to the canonical newline convention in use. (See | |||
Determining Server Newline Convention. (Section 4.3) | Determining Server Newline Convention. (Section 4.3) | |||
When a file is opened with the FXF_TEXT flag, the offset field in | When a file is opened with the FXF_TEXT flag, the offset field in | |||
both the read and write function are ignored. | both the read and write function are ignored. | |||
Servers MUST correctly process multiple parallel reads and writes | Servers MUST correctly process multiple, parallel reads and writes | |||
correctly in this mode. Naturally, it is permissible for them to | correctly in this mode. Naturally, it is permissible for them to | |||
do this by serializing the requests. It would not be possible for | do this by serializing the requests. | |||
a client to reliably detect a server that does not implement | ||||
parallel writes in time to prevent damage. | ||||
Clients SHOULD use the SSH_FXF_APPEND flag to append data to a | Clients SHOULD use the SSH_FXF_ACCESS_APPEND_DATA flag to append | |||
text file rather then using write with a calculated offset. | data to a text file rather then using write with a calculated | |||
offset. | ||||
To support seeks on text file the following SSH_FXP_EXTENDED | To support seeks on text files the following SSH_FXP_EXTENDED | |||
packet is defined. | packet is defined. | |||
string "text-seek" | string "text-seek" | |||
string file-handle | string file-handle | |||
uint64 line-number | uint64 line-number | |||
line-number is the index of the line number to seek to, where byte | line-number is the index of the line number to seek to, where byte | |||
0 in the file is line number 0, and the byte directly following | 0 in the file is line number 0, and the byte directly following | |||
the first newline sequence in the file is line number 1 and so on. | the first newline sequence in the file is line number 1 and so on. | |||
skipping to change at page 18, line 47 | skipping to change at page 24, line 38 | |||
SSH_FX_EOF status. | SSH_FX_EOF status. | |||
Servers SHOULD support at least one "text-seek" in order to | Servers SHOULD support at least one "text-seek" in order to | |||
support resume. However, a client MUST be prepared to receive | support resume. However, a client MUST be prepared to receive | |||
SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation. | SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation. | |||
The client can then try a fall-back strategy, if it has one. | The client can then try a fall-back strategy, if it has one. | |||
Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned | Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned | |||
for read or write operations that are not sequential. | for read or write operations that are not sequential. | |||
The `attrs' field specifies the initial attributes for the file. | SSH_FXF_ACCESS_READ_LOCK | |||
Default values will be used for those attributes that are not | The file should be opened with a read lock. The server MUST | |||
specified. See Section ``File Attributes'' for more information. | gaurantee that the client will be the exclusive reader of the file | |||
until the client closes the handle. If there is a conflicting lock | ||||
the server MUST return SSH_FX_LOCK_CONFlICT. If the server cannot | ||||
make the locking gaurantee, it MUST return SSH_FX_OP_UNSUPPORTED. | ||||
SSH_FXF_ACCESS_WRITE_LOCK | ||||
The file should be opened with a write lock. The server MUST | ||||
gaurantee that the client will be the exclusive writer of the file | ||||
until the client closes the handle. | ||||
SSH_FXF_ACCESS_DELETE_LOCK | ||||
The file should be opened with a delete lock. The server MUST | ||||
gaurantee that the file will not be deleted until the client | ||||
closes the handle. | ||||
The 'attrs' field specifies the initial attributes for the file. | ||||
Default values MUST be supplied by the server for those attributes | ||||
that are not specified. See Section ''File Attributes'' for more | ||||
information. | ||||
The following table is provided to assist in mapping posix semantics | ||||
to equivalent SFTP file open parameters: | ||||
O_RDONLY | ||||
desired-access = READ_DATA|READ_ATTRIBUTES | ||||
O_WRONLY | ||||
desired-access = WRITE_DATA|WRITE_ATTRIBUTES | ||||
O_RDWR | ||||
desired-access = | ||||
READ_DATA|READ_ATTRIBUTES|WRITE_DATA|WRITE_ATTRIBUTES | ||||
O_APPEND | ||||
desired-access = WRITE_DATA|WRITE_ATTRIBUTES|APPEND_DATA | ||||
flags = SSH_FXF_ACCESS_APPEND_DATA and or | ||||
SSH_FXF_ACCESS_APPEND_DATA_ATOMIC | ||||
O_CREAT | ||||
flags = SSH_FXF_OPEN_OR_CREATE | ||||
O_TRUNC | ||||
flags = SSH_FXF_TRUNCATE_EXISTING | ||||
O_TRUNC|O_CREATE | ||||
flags = SSH_FXF_CREATE_TRUNCATE | ||||
6.3.2 Opening a Directory | ||||
To enumerate a directory, the client first obtains a handle and then | ||||
issues directory read requests. When enumeration is complete, the | ||||
handle MUST be closed. | ||||
byte SSH_FXP_OPENDIR | ||||
uint32 request-id | ||||
string path [UTF-8] | ||||
'request-id' is the request identifier. | ||||
'path' is the path name of the directory to be listed (without any | ||||
trailing slash). See Section 'File Names' for more information on | ||||
file names. | ||||
The response to this message will be either SSH_FXP_HANDLE (if the | The response to this message will be either SSH_FXP_HANDLE (if the | |||
operation is successful) or SSH_FXP_STATUS (if the operation fails). | operation is successful) or SSH_FXP_STATUS (if the operation fails). | |||
A file is closed by using the SSH_FXP_CLOSE request. Its data field | 6.3.3 Closing Handles | |||
has the following format: | ||||
uint32 id | A handle is closed using the following request. | |||
byte SSH_FXP_CLOSE | ||||
uint32 request-id | ||||
string handle | string handle | |||
where `id' is the request identifier, and `handle' is a handle | 'request-id' is the request identifier, and 'handle' is a handle | |||
previously returned in the response to SSH_FXP_OPEN or | previously returned in the response to SSH_FXP_OPEN or | |||
SSH_FXP_OPENDIR. The handle becomes invalid immediately after this | SSH_FXP_OPENDIR. The handle becomes invalid immediately after this | |||
request has been sent. | request has been sent. | |||
The response to this request will be a SSH_FXP_STATUS message. One | The response to this request will be a SSH_FXP_STATUS message. Note | |||
should note that on some server platforms even a close can fail. | that on some server platforms even a close can fail. For example, if | |||
This can happen e.g. if the server operating system caches writes, | the server operating system caches writes, and an error occurs while | |||
and an error occurs while flushing cached writes during the close. | flushing cached writes, the close operation may fail. | |||
6.4 Reading and Writing | 6.4 Reading and Writing | |||
Once a file has been opened, it can be read using the following | 6.4.1 Reading Files | |||
message: | ||||
The following request can be used to read file data: | ||||
byte SSH_FXP_READ | byte SSH_FXP_READ | |||
uint32 id | uint32 request-id | |||
string handle | string handle | |||
uint64 offset | uint64 offset | |||
uint32 len | uint32 length | |||
where `id' is the request identifier, `handle' is an open file handle | where 'request-id' is the request identifier, 'handle' is an open | |||
returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative | file handle returned by SSH_FXP_OPEN, 'offset' is the offset (in | |||
to the beginning of the file from where to start reading, and `len' | bytes) relative to the beginning of the file from where to start | |||
is the maximum number of bytes to read. | reading, and 'length' is the maximum number of bytes to read. | |||
In response to this request, the server will read as many bytes as it | In response to this request, the server will read as many bytes as it | |||
can from the file (up to `len'), and return them in a SSH_FXP_DATA | can from the file (up to 'length'), and return them in a SSH_FXP_DATA | |||
message. If an error occurs or EOF is encountered before reading any | message. If an error occurs or EOF is encountered before reading any | |||
data, the server will respond with SSH_FXP_STATUS. | data, the server will respond with SSH_FXP_STATUS. | |||
For normal disk files, it is normally guaranteed that this will read | For normal disk files, it is normally guaranteed that this will read | |||
the specified number of bytes, or up to end of file. However, if the | the specified number of bytes, or up to end of file. However, if the | |||
read length is very long, the server may truncate it if it doesn't | read length is very long, the server may truncate it if it doesn't | |||
support packets of that length. See General Packet Format (Section | support packets of that length. See General Packet Format (Section | |||
3). | 3). | |||
For e.g. device files this may return fewer bytes than requested. | 6.4.2 Reading Directories | |||
In order to retrieve a directory listing, the client issues one or | ||||
more SSH_FXP_READDIR requests. In order to obtain a complete | ||||
directory listing, the client MUST issue repeated SSH_FXP_READDIR | ||||
requests until the server responds with an SSH_FXP_STATUS message. | ||||
byte SSH_FXP_READDIR | ||||
uint32 request-id | ||||
string handle | ||||
where 'request-id' is the request identifier, and 'handle' is a | ||||
handle returned by SSH_FXP_OPENDIR. (It is a protocol error to | ||||
attempt to use an ordinary file handle returned by SSH_FXP_OPEN.) | ||||
The server responds to this request with either a SSH_FXP_NAME or a | ||||
SSH_FXP_STATUS message. One or more names may be returned at a time. | ||||
Full status information is returned for each name in order to speed | ||||
up typical directory listings. | ||||
If there are no more names available to be read, the server MUST | ||||
respond with a SSH_FXP_STATUS message with error code of SSH_FX_EOF. | ||||
6.4.3 Writing Files | ||||
Writing to a file is achieved using the following message: | Writing to a file is achieved using the following message: | |||
byte SSH_FXP_WRITE | byte SSH_FXP_WRITE | |||
uint32 id | uint32 request-id | |||
string handle | string handle | |||
uint64 offset | uint64 offset | |||
string data | string data | |||
where `id' is a request identifier, `handle' is a file handle | where 'request-id' is a request identifier, 'handle' is a file handle | |||
returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the | returned by SSH_FXP_OPEN, 'offset' is the offset (in bytes) from the | |||
beginning of the file where to start writing, and `data' is the data | beginning of the file where to start writing, and 'data' is the data | |||
to be written. | to be written. | |||
The write will extend the file if writing beyond the end of the file. | The write will extend the file if writing beyond the end of the file. | |||
It is legal to write way beyond the end of the file; the semantics | It is legal to write to an offset that extends beyond the end of the | |||
are to write zeroes from the end of the file to the specified offset | file; the semantics are to write zeroes from the end of the file to | |||
and then the data. On most operating systems, such writes do not | the specified offset and then the data. On most operating systems, | |||
allocate disk space but instead leave "holes" in the file. | such writes do not allocate disk space but instead create a sparse | |||
file. | ||||
The server responds to a write request with a SSH_FXP_STATUS message. | The server responds to a write request with a SSH_FXP_STATUS message. | |||
6.5 Removing and Renaming Files | 6.5 Removing and Renaming Files | |||
Files can be removed using the SSH_FXP_REMOVE message. It has the | The following request can be used to remove a file: | |||
following format: | ||||
uint32 id | byte SSH_FXP_REMOVE | |||
uint32 request-id | ||||
string filename [UTF-8] | string filename [UTF-8] | |||
where `id' is the request identifier and `filename' is the name of | where 'request-id' is the request identifier and 'filename' is the | |||
the file to be removed. See Section ``File Names'' for more | name of the file to be removed. See Section ''File Names'' for more | |||
information. This request cannot be used to remove directories. | information. This request cannot be used to remove directories. | |||
The server will respond to this request with a SSH_FXP_STATUS | The server will respond to this request with a SSH_FXP_STATUS | |||
message. | message. | |||
Files (and directories) can be renamed using the SSH_FXP_RENAME | Files (and directories) can be renamed using the SSH_FXP_RENAME | |||
message. Its data is as follows: | message. | |||
uint32 id | byte SSH_FXP_RENAME | |||
uint32 request-id | ||||
string oldpath [UTF-8] | string oldpath [UTF-8] | |||
string newpath [UTF-8] | string newpath [UTF-8] | |||
uint32 flags | ||||
where `id' is the request identifier, `oldpath' is the name of an | where 'request-id' is the request identifier, 'oldpath' is the name | |||
existing file or directory, and `newpath' is the new name for the | of an existing file or directory, and 'newpath' is the new name for | |||
file or directory. It is an error if there already exists a file | the file or directory. | |||
with the name specified by newpath. The server may also fail rename | ||||
requests in other situations, for example if `oldpath' and `newpath' | 'flags' is 0 or a combination of: | |||
point to different file systems on the server. | ||||
SSH_FXP_RENAME_OVERWRITE 0x00000001 | ||||
SSH_FXP_RENAME_ATOMIC 0x00000002 | ||||
SSH_FXP_RENAME_NATIVE 0x00000004 | ||||
If flags does not include SSH_FXP_RENAME_OVERWRITE, and there already | ||||
exists a file with the name specified by newpath, the server MUST | ||||
respond with SSH_FX_FILE_ALREADY_EXISTS. | ||||
If flags includes SSH_FXP_RENAME_ATOMIC, and the destination file | ||||
already exists, it is replaced in an atomic fashion. I.e., there is | ||||
no observable instant in time where the name does not refer to either | ||||
the old or the new file. SSH_FXP_RENAME_ATOMIC implies | ||||
SSH_FXP_RENAME_OVERWRITE. | ||||
If flags includes SSH_FXP_RENAME_ATOMIC and the server cannot replace | ||||
the destination in an atomic fashion, then the server MUST respond | ||||
with SSH_FX_OP_UNSUPPORTED. | ||||
Because some servers cannot provide atomic rename, clients should | ||||
only specify atomic rename if correct operation requires it. If | ||||
SSH_FXP_RENAME_OVERWRITE is specified, the server MAY perform an | ||||
atomic rename even if it is not requested. | ||||
If flags includes SSH_FXP_RENAME_NATIVE, the server is free to do the | ||||
rename operation in whatever fashion it deems appropriate. Other | ||||
flag values are considered hints as to desired behavior, but not | ||||
requirements. | ||||
The server will respond to this request with a SSH_FXP_STATUS | The server will respond to this request with a SSH_FXP_STATUS | |||
message. | message. | |||
6.6 Creating and Deleting Directories | 6.6 Creating and Deleting Directories | |||
New directories can be created using the SSH_FXP_MKDIR request. It | New directories can be created using the SSH_FXP_MKDIR request. It | |||
has the following format: | has the following format: | |||
uint32 id | byte SSH_FXP_MKDIR | |||
uint32 request-id | ||||
string path [UTF-8] | string path [UTF-8] | |||
ATTRS attrs | ATTRS attrs | |||
where `id' is the request identifier. | where 'request-id' is the request identifier. | |||
`path' specifies the directory to be created. See Section ``File | 'path' specifies the directory to be created. See Section ''File | |||
Names'' for more information on file names. | Names'' for more information on file names. | |||
`attrs' specifies the attributes that should be applied to it upon | 'attrs' specifies the attributes that should be applied to it upon | |||
creation. Attributes are discussed in more detail in Section ``File | creation. Attributes are discussed in more detail in Section ''File | |||
Attributes''. | Attributes''. | |||
The server will respond to this request with a SSH_FXP_STATUS | The server will respond to this request with a SSH_FXP_STATUS | |||
message. If a file or directory with the specified path already | message. If a file or directory with the specified path already | |||
exists, an error will be returned. | exists, an error will be returned. | |||
Directories can be removed using the SSH_FXP_RMDIR request, which has | Directories can be removed using the SSH_FXP_RMDIR request, which has | |||
the following format: | the following format: | |||
uint32 id | byte SSH_FXP_RMDIR | |||
uint32 request-id | ||||
string path [UTF-8] | string path [UTF-8] | |||
where `id' is the request identifier, and `path' specifies the | where 'request-id' is the request identifier, and 'path' specifies | |||
directory to be removed. See Section ``File Names'' for more | the directory to be removed. See Section ''File Names'' for more | |||
information on file names. | information on file names. | |||
The server responds to this request with a SSH_FXP_STATUS message. | The server responds to this request with a SSH_FXP_STATUS message. | |||
Errors may be returned from this operation for various reasons, | ||||
including, but not limited to, the path does not exist, the path does | ||||
not refer to a directory object, the directory is not empty, or the | ||||
user has insufficient access or permission to perform the requested | ||||
operation. | ||||
6.7 Scanning Directories | ||||
The files in a directory can be listed using the SSH_FXP_OPENDIR and | ||||
SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one | ||||
or more file names with full file attributes for each file. The | ||||
client should call SSH_FXP_READDIR repeatedly until it has found the | ||||
file it is looking for or until the server responds with a | ||||
SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if | ||||
there are no more files in the directory). The client should then | ||||
close the handle using the SSH_FXP_CLOSE request. | ||||
The SSH_FXP_OPENDIR opens a directory for reading. It has the | 6.7 Retrieving File Attributes | |||
following format: | ||||
uint32 id | ||||
string path [UTF-8] | ||||
where `id' is the request identifier and `path' is the path name of | ||||
the directory to be listed (without any trailing slash). See Section | ||||
``File Names'' for more information on file names. This will return | ||||
an error if the path does not specify a directory or if the directory | ||||
is not readable. The server will respond to this request with either | ||||
a SSH_FXP_HANDLE or a SSH_FXP_STATUS message. | ||||
Once the directory has been successfully opened, files (and | ||||
directories) contained in it can be listed using SSH_FXP_READDIR | ||||
requests. These are of the format | ||||
uint32 id | ||||
string handle | ||||
where `id' is the request identifier, and `handle' is a handle | ||||
returned by SSH_FXP_OPENDIR. (It is a protocol error to attempt to | ||||
use an ordinary file handle returned by SSH_FXP_OPEN.) | ||||
The server responds to this request with either a SSH_FXP_NAME or a | ||||
SSH_FXP_STATUS message. One or more names may be returned at a time. | ||||
Full status information is returned for each name in order to speed | ||||
up typical directory listings. | ||||
If there are no more names available to be read, the server MUST | ||||
respond with a SSH_FXP_STATUS message with error code of SSH_FX_EOF. | ||||
When the client no longer wishes to read more names from the | ||||
directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle | ||||
should be closed regardless of whether an error has occurred or not. | ||||
6.8 Retrieving File Attributes | ||||
Very often, file attributes are automatically returned by | Very often, file attributes are automatically returned by | |||
SSH_FXP_READDIR. However, sometimes there is need to specifically | SSH_FXP_READDIR. However, sometimes there is need to specifically | |||
retrieve the attributes for a named file. This can be done using the | retrieve the attributes for a named file. This can be done using the | |||
SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests. | SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests. | |||
SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT | SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT | |||
follows symbolic links on the server, whereas SSH_FXP_LSTAT does not | follows symbolic links on the server, whereas SSH_FXP_LSTAT does not | |||
follow symbolic links. Both have the same format: | follow symbolic links. Both have the same format: | |||
uint32 id | byte SSH_FXP_STAT or SSH_FXP_LSTAT | |||
uint32 request-id | ||||
string path [UTF-8] | string path [UTF-8] | |||
uint32 flags | uint32 flags | |||
where `id' is the request identifier, and `path' specifies the file | where 'request-id' is the request identifier, and 'path' specifies | |||
system object for which status is to be returned. The server | the file system object for which status is to be returned. The | |||
responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS. | server responds to this request with either SSH_FXP_ATTRS or | |||
SSH_FXP_STATUS. | ||||
The flags field specify the attribute flags in which the client has | The flags field specify the attribute flags in which the client has | |||
particular interest. This is a hint to the server. For example, | particular interest. This is a hint to the server. For example, | |||
because retrieving owner / group and acl information can be an | because retrieving owner / group and acl information can be an | |||
expensive operation under some operating systems, the server may | expensive operation under some operating systems, the server may | |||
choose not to retrieve this information unless the client expresses a | choose not to retrieve this information unless the client expresses a | |||
specific interest in it. | specific interest in it. | |||
The client has no guarantee the server will provide all the fields | The client has no guarantee the server will provide all the fields | |||
that it has expressed an interest in. | that it has expressed an interest in. | |||
SSH_FXP_FSTAT differs from the others in that it returns status | SSH_FXP_FSTAT differs from the others in that it returns status | |||
information for an open file (identified by the file handle). Its | information for an open file (identified by the file handle). | |||
format is as follows: | ||||
uint32 id | byte SSH_FXP_FSTAT | |||
uint32 request-id | ||||
string handle | string handle | |||
uint32 flags | uint32 flags | |||
where `id' is the request identifier and `handle' is a file handle | where 'request-id' is the request identifier and 'handle' is a file | |||
returned by SSH_FXP_OPEN. The server responds to this request with | handle returned by SSH_FXP_OPEN. The server responds to this request | |||
SSH_FXP_ATTRS or SSH_FXP_STATUS. | with SSH_FXP_ATTRS or SSH_FXP_STATUS. | |||
6.9 Setting File Attributes | 6.8 Setting File Attributes | |||
File attributes may be modified using the SSH_FXP_SETSTAT and | File attributes may be modified using the SSH_FXP_SETSTAT and | |||
SSH_FXP_FSETSTAT requests. These requests are used for operations | SSH_FXP_FSETSTAT requests. | |||
such as changing the ownership, permissions or access times, as well | ||||
as for truncating a file. | ||||
The SSH_FXP_SETSTAT request is of the following format: | ||||
uint32 id | byte SSH_FXP_SETSTAT | |||
uint32 request-id | ||||
string path [UTF-8] | string path [UTF-8] | |||
ATTRS attrs | ATTRS attrs | |||
where `id' is the request identifier, `path' specifies the file | byte SSH_FXP_FSETSTAT | |||
system object (e.g. file or directory) whose attributes are to be | uint32 request-id | |||
modified, and `attrs' specifies the modifications to be made to its | string handle | |||
attributes. Attributes are discussed in more detail in Section | ATTRS attrs | |||
``File Attributes''. | ||||
An error will be returned if the specified file system object does | request-id | |||
not exist or the user does not have sufficient rights to modify the | The request identifier to be returned as part of the response. | |||
specified attributes. The server responds to this request with a | ||||
SSH_FXP_STATUS message. | ||||
The SSH_FXP_FSETSTAT request modifies the attributes of a file which | path | |||
is already open. It has the following format: | The file system object (e.g. file or directory) whose attributes | |||
are to be modified. If this object does not exist, or the user | ||||
does not have sufficient access to write the attributes, the | ||||
request MUST fail. | ||||
uint32 id | handle | |||
string handle | The handle is a handle previously returned from a SSH_FXP_OPEN | |||
ATTRS attrs | request which identifies the file whose attributes are to be | |||
modified. If the handle was not opened with sufficient access to | ||||
write the requested attributes, the request MUST fail. | ||||
where `id' is the request identifier, `handle' (MUST be returned by | attrs | |||
SSH_FXP_OPEN) identifies the file whose attributes are to be | Specifies the modified attributes to be applied. Attributes are | |||
modified, and `attrs' specifies the modifications to be made to its | discussed in more detail in Section ''File Attributes''. | |||
attributes. Attributes are discussed in more detail in Section | ||||
``File Attributes''. The server will respond to this request with | ||||
SSH_FXP_STATUS. | ||||
6.10 Dealing with Symbolic links | The server will respond with a SSH_FXP_STATUS message. | |||
The SSH_FXP_READLINK request may be used to read the target of a | Because some systems must use separate system calls to set various | |||
symbolic link. It would have a data part as follows: | attributes, it is possible that a failure response will be returned, | |||
but yet some of the attributes may be have been successfully | ||||
modified. If possible, servers SHOULD avoid this situation; however, | ||||
client MUST be aware that this is possible. | ||||
uint32 id | 6.9 Dealing with Symbolic Links | |||
string path [UTF-8] | ||||
where `id' is the request identifier and `path' specifies the path | The SSH_FXP_READLINK request reads the target of a symbolic link. | |||
name of the symlink to be read. | ||||
byte SSH_FXP_READLINK | ||||
uint32 request-id | ||||
string path [UTF-8] | ||||
where 'request-id' is the request identifier and 'path' specifies the | ||||
path name of the symlink to be read. | ||||
The server will respond with a SSH_FXP_NAME packet containing only | The server will respond with a SSH_FXP_NAME packet containing only | |||
one name and a dummy attributes value. The name in the returned | one name and a dummy attributes value. The name in the returned | |||
packet contains the target of the link. If an error occurs, the | packet contains the target of the link. If an error occurs, the | |||
server may respond with SSH_FXP_STATUS. | server MAY respond with SSH_FXP_STATUS. | |||
The SSH_FXP_SYMLINK request will create a symbolic link on the | The SSH_FXP_SYMLINK request creates a symbolic link on the server. | |||
server. It is of the following format | ||||
uint32 id | byte SSH_FXP_SYMLINK | |||
uint32 request-id | ||||
string linkpath [UTF-8] | string linkpath [UTF-8] | |||
string targetpath [UTF-8] | string targetpath [UTF-8] | |||
where `id' is the request identifier, `linkpath' specifies the path | where 'request-id' is the request identifier, 'linkpath' specifies | |||
name of the symlink to be created and `targetpath' specifies the | the path name of the symlink to be created and 'targetpath' specifies | |||
target of the symlink. The server shall respond with a | the target of the symlink. The server shall respond with a | |||
SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error | SSH_FXP_STATUS. | |||
condition. | ||||
6.11 Canonicalizing the Server-Side Path Name | 6.10 Canonicalizing the Server-Side Path Name | |||
The SSH_FXP_REALPATH request can be used to have the server | The SSH_FXP_REALPATH request can be used to have the server | |||
canonicalize any given path name to an absolute path. This is useful | canonicalize any given path name to an absolute path. This is useful | |||
for converting path names containing ".." components or relative | for converting path names containing ".." components or relative | |||
pathnames without a leading slash into absolute paths. The format of | pathnames without a leading slash into absolute paths. The format of | |||
the request is as follows: | the request is as follows: | |||
uint32 id | byte SSH_FXP_REALPATH | |||
uint32 request-id | ||||
string path [UTF-8] | string path [UTF-8] | |||
where `id' is the request identifier and `path' specifies the path | where 'request-id' is the request identifier and 'path' specifies the | |||
name to be canonicalized. The server will respond with a | path name to be canonicalized. The server will respond with a | |||
SSH_FXP_NAME packet containing the name in canonical form and a dummy | SSH_FXP_NAME packet containing the name in canonical form and a dummy | |||
attributes value. If an error occurs, the server may also respond | attributes value. If an error occurs, the server may also respond | |||
with SSH_FXP_STATUS. | with SSH_FXP_STATUS. | |||
6.11.1 Best practice for dealing with paths | The server SHOULD fail the request if the path is not present on the | |||
server. | ||||
6.10.1 Best Practice for Dealing with Paths | ||||
The client SHOULD treat the results of SSH_FXP_REALPATH as a | The client SHOULD treat the results of SSH_FXP_REALPATH as a | |||
canonical absolute path, even if the path does not appear to be | canonical absolute path, even if the path does not appear to be | |||
absolute. A client that use REALPATH(".") and treats the result as | absolute. A client that use REALPATH(".") and treats the result as | |||
absolute, even if there is no leading slash, will continue to | absolute, even if there is no leading slash, will continue to | |||
function correctly, even when talking to a Windows NT or VMS style | function correctly, even when talking to a Windows NT or VMS style | |||
system, where absolute paths may not begin with a slash. | system, where absolute paths may not begin with a slash. | |||
For example, if the client wishes to change directory up, and the | For example, if the client wishes to change directory up, and the | |||
server has returned "c:/x/y/z" from REALPATH, the client SHOULD use | server has returned "c:/x/y/z" from REALPATH, the client SHOULD use | |||
skipping to change at page 26, line 9 | skipping to change at page 34, line 9 | |||
As a second example, if the client wishes to open the file "x.txt" in | As a second example, if the client wishes to open the file "x.txt" in | |||
the current directory, and server has returned "dka100:/x/y/z" as the | the current directory, and server has returned "dka100:/x/y/z" as the | |||
canonical path of the directory, the client SHOULD open "dka100:/x/y/ | canonical path of the directory, the client SHOULD open "dka100:/x/y/ | |||
z/x.txt" | z/x.txt" | |||
7. Responses from the Server to the Client | 7. Responses from the Server to the Client | |||
The server responds to the client using one of a few response | The server responds to the client using one of a few response | |||
packets. All requests can return a SSH_FXP_STATUS response upon | packets. All requests can return a SSH_FXP_STATUS response upon | |||
failure. When the operation is successful, any of the responses may | failure. When the operation is successful, and no data needs to be | |||
be returned (depending on the operation). If no data needs to be | returned, the SSH_FXP_STATUS response with SSH_FX_OK status is | |||
returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK | appropriate. | |||
status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used | ||||
to return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR | ||||
requests), SSH_FXP_DATA is used to return data from SSH_FXP_READ, | ||||
SSH_FXP_NAME is used to return one or more file names from a | ||||
SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is | ||||
used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and | ||||
SSH_FXP_FSTAT requests. | ||||
Exactly one response will be returned for each request. Each | Exactly one response will be returned for each request. Each | |||
response packet contains a request identifier which can be used to | response packet contains a request identifier which can be used to | |||
match each response with the corresponding request. Note that it is | match each response with the corresponding request. Note that it is | |||
legal to have several requests outstanding simultaneously, and the | legal to have several requests outstanding simultaneously, and the | |||
server is allowed to send responses to them in a different order from | server is allowed to send responses to them in a different order from | |||
the order in which the requests were sent (the result of their | the order in which the requests were sent (the result of their | |||
execution, however, is guaranteed to be as if they had been processed | execution, however, is guaranteed to be as if they had been processed | |||
one at a time in the order in which the requests were sent). | one at a time in the order in which the requests were sent). | |||
Response packets are of the same general format as request packets. | Response packets are of the same general format as request packets. | |||
Each response packet begins with the request identifier. | Each response packet begins with the request identifier. | |||
The format of the data portion of the SSH_FXP_STATUS response is as | The format of the data portion of the SSH_FXP_STATUS response is as | |||
follows: | follows: | |||
uint32 id | byte SSH_FXP_STATUS | |||
uint32 request-id | ||||
uint32 error/status code | uint32 error/status code | |||
string error message (ISO-10646 UTF-8 [RFC-2279]) | string error message (ISO-10646 UTF-8 [RFC-2279]) | |||
string language tag (as defined in [RFC-1766]) | string language tag (as defined in [RFC-1766]) | |||
<error-specific data> | ||||
where `id' is the request identifier, and `error/status code' | request-id | |||
indicates the result of the requested operation. The value SSH_FX_OK | The 'request-id' specified by the client in the request the server | |||
is responding to. | ||||
error/status code | ||||
Machine readable status code indicating the result of the request. | ||||
Error code values are defined below. The value SSH_FX_OK | ||||
indicates success, and all other values indicate failure. | indicates success, and all other values indicate failure. | |||
Currently, the following values are defined (other values may be | error message | |||
defined by future versions of this protocol): | Human readable description of the error. 'language tag' specifies | |||
the language the error is in. | ||||
<error-specific data> | ||||
The error-specific data may be empty, or may contain additional | ||||
information about the error. For error codes that send | ||||
error-specific data, the format of the data is defined below. | ||||
Error codes: | ||||
#define SSH_FX_OK 0 | #define SSH_FX_OK 0 | |||
#define SSH_FX_EOF 1 | #define SSH_FX_EOF 1 | |||
#define SSH_FX_NO_SUCH_FILE 2 | #define SSH_FX_NO_SUCH_FILE 2 | |||
#define SSH_FX_PERMISSION_DENIED 3 | #define SSH_FX_PERMISSION_DENIED 3 | |||
#define SSH_FX_FAILURE 4 | #define SSH_FX_FAILURE 4 | |||
#define SSH_FX_BAD_MESSAGE 5 | #define SSH_FX_BAD_MESSAGE 5 | |||
#define SSH_FX_NO_CONNECTION 6 | #define SSH_FX_NO_CONNECTION 6 | |||
#define SSH_FX_CONNECTION_LOST 7 | #define SSH_FX_CONNECTION_LOST 7 | |||
#define SSH_FX_OP_UNSUPPORTED 8 | #define SSH_FX_OP_UNSUPPORTED 8 | |||
#define SSH_FX_INVALID_HANDLE 9 | #define SSH_FX_INVALID_HANDLE 9 | |||
#define SSH_FX_NO_SUCH_PATH 10 | #define SSH_FX_NO_SUCH_PATH 10 | |||
#define SSH_FX_FILE_ALREADY_EXISTS 11 | #define SSH_FX_FILE_ALREADY_EXISTS 11 | |||
#define SSH_FX_WRITE_PROTECT 12 | #define SSH_FX_WRITE_PROTECT 12 | |||
#define SSH_FX_NO_MEDIA 13 | #define SSH_FX_NO_MEDIA 13 | |||
#define SSH_FX_NO_SPACE_ON_FILESYSTEM 14 | ||||
#define SSH_FX_QUOTA_EXCEEDED 15 | ||||
#define SSH_FX_UNKNOWN_PRINCIPLE 16 | ||||
#define SSH_FX_LOCK_CONFlICT 17 | ||||
SSH_FX_OK | SSH_FX_OK | |||
Indicates successful completion of the operation. | Indicates successful completion of the operation. | |||
SSH_FX_EOF | SSH_FX_EOF | |||
indicates end-of-file condition; for SSH_FX_READ it means that no | An attempt to read past the end-of-file was made; or, there are no | |||
more data is available in the file, and for SSH_FX_READDIR it | more directory entries to return. | |||
indicates that no more files are contained in the directory. | ||||
SSH_FX_NO_SUCH_FILE | SSH_FX_NO_SUCH_FILE | |||
is returned when a reference is made to a file which does not | A reference was made to a file which does not exist. | |||
exist. | ||||
SSH_FX_PERMISSION_DENIED | SSH_FX_PERMISSION_DENIED | |||
is returned when the authenticated user does not have sufficient | The user does not have sufficient permissions to perform the | |||
permissions to perform the operation. | operation. | |||
SSH_FX_FAILURE | SSH_FX_FAILURE | |||
is a generic catch-all error message; it should be returned if an | An error occured, but no specific error code exists to describe | |||
error occurs for which there is no more specific error code | the failure. | |||
defined. | ||||
This error message SHOULD always have meaningful text in the the | ||||
'error message' field. | ||||
SSH_FX_BAD_MESSAGE | SSH_FX_BAD_MESSAGE | |||
may be returned if a badly formatted packet or protocol | A badly formatted packet or other SFTP protocol incompatibility | |||
incompatibility is detected. | was detected. | |||
SSH_FX_NO_CONNECTION | SSH_FX_NO_CONNECTION | |||
is a pseudo-error which indicates that the client has no | There is no connection to the server. This error can only be | |||
connection to the server (it can only be generated locally by the | generated locally, and MUST NOT be return by a server. | |||
client, and MUST NOT be returned by servers). | ||||
SSH_FX_CONNECTION_LOST | SSH_FX_CONNECTION_LOST | |||
is a pseudo-error which indicates that the connection to the | The connection to the server was lost. This error can only be | |||
server has been lost (it can only be generated locally by the | generated locally, and MUST NOT be return by a server. | |||
client, and MUST NOT be returned by servers). | ||||
SSH_FX_OP_UNSUPPORTED | SSH_FX_OP_UNSUPPORTED | |||
indicates that an attempt was made to perform an operation which | An attempted operation could not be completed by the server | |||
is not supported for the server (it may be generated locally by | because the server does not support the operation. | |||
the client if e.g. the version number exchange indicates that a | ||||
required feature is not supported by the server, or it may be | This error MAY be generated locally by the client if e.g. the | |||
returned by the server if the server does not implement an | version number exchange indicates that a required feature is not | |||
operation). | supported by the server, or it may be returned by the server if | |||
the server does not implement an operation). | ||||
SSH_FX_INVALID_HANDLE | SSH_FX_INVALID_HANDLE | |||
The handle value was invalid. | The handle value was invalid. | |||
SSH_FX_NO_SUCH_PATH | SSH_FX_NO_SUCH_PATH | |||
The file path does not exist or is invalid. | The file path does not exist or is invalid. | |||
SSH_FX_FILE_ALREADY_EXISTS | SSH_FX_FILE_ALREADY_EXISTS | |||
The file already exists. | The file already exists. | |||
SSH_FX_WRITE_PROTECT | SSH_FX_WRITE_PROTECT | |||
The file is on read only media, or the media is write protected. | The file is on read-only media, or the media is write protected. | |||
SSH_FX_NO_MEDIA | SSH_FX_NO_MEDIA | |||
The requested operation can not be completed because there is no | The requested operation can not be completed because there is no | |||
media available in the drive. | media available in the drive. | |||
SSH_FX_NO_SPACE_ON_FILESYSTEM | ||||
The requested operation cannot be completed because there is no | ||||
free space on the filesystem. | ||||
SSH_FX_QUOTA_EXCEEDED | ||||
The operation cannot be completed because the it would exceed the | ||||
users storage quota. | ||||
SSH_FX_UNKNOWN_PRINCIPLE | ||||
A principle referenced by the request (either the 'owner', | ||||
'group', or 'who' field of an ACL), was unknown. The error | ||||
specific data contains the problematic names. The format is one | ||||
or more: | ||||
string unknown-name | ||||
Each string contains the name of a principle that was unknown. | ||||
SSH_FX_LOCK_CONFlICT | ||||
The file could not be opened because it is locked by another | ||||
process. | ||||
The SSH_FXP_HANDLE response has the following format: | The SSH_FXP_HANDLE response has the following format: | |||
uint32 id | byte SSH_FXP_HANDLE | |||
uint32 request-id | ||||
string handle | string handle | |||
where `id' is the request identifier, and `handle' is an arbitrary | where 'request-id' is the request identifier, and 'handle' is an | |||
string that identifies an open file or directory on the server. The | arbitrary string that identifies an open file or directory on the | |||
handle is opaque to the client; the client MUST NOT attempt to | server. The handle is opaque to the client; the client MUST NOT | |||
interpret or modify it in any way. The length of the handle string | attempt to interpret or modify it in any way. The length of the | |||
MUST NOT exceed 256 data bytes. | handle string MUST NOT exceed 256 data bytes. | |||
The SSH_FXP_DATA response has the following format: | The SSH_FXP_DATA response has the following format: | |||
uint32 id | byte SSH_FXP_DATA | |||
uint32 request-id | ||||
string data | string data | |||
where `id' is the request identifier, and `data' is an arbitrary byte | where 'request-id' is the request identifier, and 'data' is an | |||
string containing the requested data. The data string may be at most | arbitrary byte string containing the requested data. The data string | |||
the number of bytes requested in a SSH_FXP_READ request, but may also | may be at most the number of bytes requested in a SSH_FXP_READ | |||
be shorter if end of file is reached or if the read is from something | request, but may also be shorter if end of file is reached or if the | |||
other than a regular file. | read is from something other than a regular file. | |||
The SSH_FXP_NAME response has the following format: | The SSH_FXP_NAME response has the following format: | |||
uint32 id | byte SSH_FXP_NAME | |||
uint32 request-id | ||||
uint32 count | uint32 count | |||
repeats count times: | repeats count times: | |||
string filename [UTF-8] | string filename [UTF-8] | |||
ATTRS attrs | ATTRS attrs | |||
where `id' is the request identifier, `count' is the number of names | where 'request-id' is the request identifier, 'count' is the number | |||
returned in this response, and the remaining fields repeat `count' | of names returned in this response, and the remaining fields repeat | |||
times (so that all three fields are first included for the first | 'count' times. In the repeated part, 'filename' is a file name being | |||
file, then for the second file, etc). In the repeated part, | returned (for SSH_FXP_READDIR, it will be a relative name within the | |||
`filename' is a file name being returned (for SSH_FXP_READDIR, it | directory, without any path components; for SSH_FXP_REALPATH it will | |||
will be a relative name within the directory, without any path | be an absolute path name), and 'attrs' is the attributes of the file | |||
components; for SSH_FXP_REALPATH it will be an absolute path name), | as described in Section ''File Attributes''. | |||
and `attrs' is the attributes of the file as described in Section | ||||
``File Attributes''. | ||||
The SSH_FXP_ATTRS response has the following format: | The SSH_FXP_ATTRS response has the following format: | |||
uint32 id | byte SSH_FXP_ATTRS | |||
uint32 request-id | ||||
ATTRS attrs | ATTRS attrs | |||
where `id' is the request identifier, and `attrs' is the returned | where 'request-id' is the request identifier, and 'attrs' is the | |||
file attributes as described in Section ``File Attributes''. | returned file attributes as described in Section ''File Attributes''. | |||
8. Vendor-Specific Extensions | 8. Extensions | |||
The SSH_FXP_EXTENDED request provides a generic extension mechanism | The SSH_FXP_EXTENDED request provides a generic extension mechanism | |||
for adding vendor-specific commands. The request has the following | for adding additional commands. | |||
format: | ||||
uint32 id | byte SSH_FXP_EXTENDED | |||
uint32 request-id | ||||
string extended-request | string extended-request | |||
... any request-specific data ... | ... any request-specific data ... | |||
where `id' is the request identifier, and `extended-request' is a | request-id | |||
string of the format "name@domain", where domain is an internet | Identifier to be returned from the server with the response. | |||
domain name of the vendor defining the request. The rest of the | ||||
request is completely vendor-specific, and servers should only | extended-request | |||
attempt to interpret it if they recognize the `extended-request' | A string naming the extension. Vendor-specific extensions have | |||
name. | use the "name@domain" syntax, where domain is an internet domain | |||
name of the vendor defining the request. | ||||
The IETF may also define extensions to the protocol. These | ||||
extension names will not have an '@' in them. | ||||
request-specific data | ||||
The rest of the request is defined by the extension, and servers | ||||
should only attempt to interpret it if they recognize the | ||||
'extended-request' name. | ||||
The server may respond to such requests using any of the response | The server may respond to such requests using any of the response | |||
packets defined in Section ``Responses from the Server to the | packets defined in Section ''Responses from the Server to the | |||
Client''. Additionally, the server may also respond with a | Client''. Additionally, the server may also respond with a | |||
SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does | SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does | |||
not recognize the `extended-request' name, then the server MUST | not recognize the 'extended-request' name, then the server MUST | |||
respond with SSH_FXP_STATUS with error/status set to | respond with SSH_FXP_STATUS with error/status set to | |||
SSH_FX_OP_UNSUPPORTED. | SSH_FX_OP_UNSUPPORTED. | |||
The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary | The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary | |||
extension-specific data from the server to the client. It is of the | extension-specific data from the server to the client. It is of the | |||
following format: | following format: | |||
uint32 id | byte SSH_FXP_EXTENDED_REPLY | |||
uint32 request-id | ||||
... any request-specific data ... | ... any request-specific data ... | |||
There is a range of packet types reserved for use by extensions. In | There is a range of packet types reserved for use by extensions. In | |||
order to avoid collision, extensions that turn on the use of | order to avoid collision, extensions that that use additional packet | |||
additional packet types should determine those numbers dynamically. | types should determine those numbers dynamically. | |||
The suggested way of doing this is have an extension request from the | The suggested way of doing this is have an extension request from the | |||
client to the server that enables the extension; the extension | client to the server that enables the extension; the extension | |||
response from the server to the client would specify the actual type | response from the server to the client would specify the actual type | |||
values to use, in additional to any other data. | values to use, in additional to any other data. | |||
Extension authors should be mindful of the limited range of packet | Extension authors should be mindful of the limited range of packet | |||
types available (there are only 45 values available) and avoid | types available (there are only 45 values available) and avoid | |||
requiring a new packet type where possible. | requiring a new packet type where possible. | |||
8.1 Checking File Contents | ||||
This extension allows a client to easily check if a file (or portion | ||||
thereof) that it already has matches what is on the server. | ||||
byte SSH_FXP_EXTENDED | ||||
uint32 request-id | ||||
string "md5-hash" / "md5-hash-handle" | ||||
string filename / file-handle | ||||
uint64 start-offset | ||||
uint64 length | ||||
string quick-check-hash | ||||
filename | ||||
Used if "md5-hash" is specified; indicates the name of the file to | ||||
use. | ||||
file-handle | ||||
Used if "md5-hash-handle" is specified; specifies a file handle to | ||||
read the data from. The handle MUST be a file handle, and | ||||
ACE4_READ_DATA MUST have been included in the desired-access when | ||||
the fail was opened. | ||||
start-offset | ||||
The starting offset of the data to hash. | ||||
length | ||||
The length of data to include in the hash. If both start-offset | ||||
and length are zero, the entire file should be included. | ||||
quick-check-hash | ||||
The hash over the first 2048 bytes of the data range as the client | ||||
knows it, or the entire range, if it is less than 2048 bytes. | ||||
This allows the server to quickly check if it is worth the | ||||
resources to hash a big file. | ||||
If this is a zero length string, the client does not have the | ||||
data, and is requesting the hash for reasons other than comparing | ||||
with a local file. The server MAY return SSH_FX_OP_UNSUPPORTED in | ||||
this case. | ||||
The response is either a SSH_FXP_STATUS packet, indicating an error, | ||||
or the following extended reply packet: | ||||
byte SSH_FXP_EXTENDED_REPLY | ||||
uint32 request-id | ||||
string "md5-hash" | ||||
string hash | ||||
If 'hash' is zero length, then the 'quick-check-hash' did not match, | ||||
and no hash operation was preformed. Otherwise, 'hash' contains the | ||||
hash of the entire data range (including the first 2048 bytes that | ||||
were included in the 'quick-check-hash'.) | ||||
9. Security Considerations | 9. Security Considerations | |||
This protocol assumes that it is run over a secure channel and that | It is assumed that both ends of the connection have been | |||
the endpoints of the channel have been authenticated. Thus, this | authenticated and that the connection has privacy and integrity | |||
protocol assumes that it is externally protected from network-level | features. Such security issues are left to the underlying transport | |||
attacks. | protocol, except to note that if this is not the case, an attacker | |||
could manipulate files on the server at will and thus wholly | ||||
compromise the server. | ||||
This protocol provides file system access to arbitrary files on the | This protocol provides file system access to arbitrary files on the | |||
server (only constrained by the server implementation). It is the | server (only constrained by the server implementation). It is the | |||
responsibility of the server implementation to enforce any access | responsibility of the server implementation to enforce any access | |||
controls that may be required to limit the access allowed for any | controls that may be required to limit the access allowed for any | |||
particular user (the user being authenticated externally to this | particular user (the user being authenticated externally to this | |||
protocol, typically using the SSH User Authentication Protocol [8]. | protocol, typically using the SSH User Authentication Protocol [8]. | |||
Care must be taken in the server implementation to check the validity | Extreme care must be used when interpreting file handle strings. In | |||
of received file handle strings. The server should not rely on them | particular, care must be taken that a file handle string is valid in | |||
directly; it MUST check the validity of each handle before relying on | the context of a given SFTP session. For example, the sftp server | |||
it. | daemon may have files which it has opened for its own purposes, and | |||
the client must not be able to access these files by specifying an | ||||
arbitrary file handle string. | ||||
10. Changes from previous protocol versions | The permission field of the attrib structure (Section 5.5) may | |||
include the SUID, SGID, and SVTX (sticky) bits. Clients should use | ||||
extreme caution when setting these bits on either remote or local | ||||
files. (I.e., just because a file was SUID on the remote system does | ||||
not necessarily imply that it should be SUID on the local system.) | ||||
The SSH File Transfer Protocol has changed over time, before it's | Filesystems often contain entries for objects that are not files at | |||
all, but are rather devices. For example, it may be possible to | ||||
access serial ports, tape devices, or named pipes using this | ||||
protocol. Servers should exercise caution when granting access to | ||||
such resources. In addition to the dangers inherent in allowing | ||||
access to such a device, some devices may be 'slow', and could cause | ||||
denial of service by causing the server to block for a long period of | ||||
time while I/O is performed to such a device. | ||||
Servers should take care that file-system quotas are respected for | ||||
users. In addition, implementations should be aware that attacks may | ||||
be possible, or facilitated, by filling a filesystem. For example, | ||||
filling the filesystem where event logging and auditing occurs may, | ||||
at best, cause the system to crash, or at worst, allow the attacker | ||||
to take untraceable actions in the future. | ||||
Servers should take care that filenames are in their appropriate | ||||
canonical form, and to insure that filenames not in canonical form | ||||
cannot be used to bypass access checks or controls. | ||||
10. Changes from Previous Protocol Versions | ||||
The SSH File Transfer Protocol has changed over time, before its | ||||
standardization. The following is a description of the incompatible | standardization. The following is a description of the incompatible | |||
changes between different versions. | changes between different versions. | |||
10.1 Changes between versions 4 and 3 | 10.1 Changes Between Versions 5 and 4 | |||
Many of the changes between version 5 and version 4 are to better | ||||
support the changes in version 4, and to better specify error | ||||
conditions. | ||||
o Add "supported" extension to communicate features supported. | ||||
o Clarify error handling when client requests unsupported feature. | ||||
(For example, attempts to write an unsupported attribute.) | ||||
o Add attrib-bits field to the attribute structure, which specifies | ||||
a number of boolean attributes related to files and directories, | ||||
including advisory read-only and case-sensitivity bits. | ||||
o Clarify the actual bit values to be used for the permissions field | ||||
(since posix doesn't define values) and correct the value of | ||||
ATTR_PERMISSIONS flag. | ||||
o Some reordering of sections to attempt to get a better grouping of | ||||
related functionality. | ||||
o Open request explicitly specifies the access desired for the file. | ||||
o Add support for explicitly requesting file locking. | ||||
o Add support for better control of the rename operation. | ||||
o Add SSH_FX_NO_SPACE_ON_FILESYSTEM, SSH_FX_QUOTA_EXCEEDED, and | ||||
SSH_FX_UNKNOWN_PRINCIPLE error codes. | ||||
o Add support for error specific data. This is used by a new | ||||
SSH_FX_UNKNOWN_PRINCIPLE error to communicate which principles are | ||||
unknown. | ||||
o Add support for retrieving md5-hash of file contents. | ||||
o Update security section. | ||||
10.2 Changes Between Versions 4 and 3 | ||||
Many of the changes between version 4 and version 3 are to the | Many of the changes between version 4 and version 3 are to the | |||
attribute structure to make it more flexible for non-unix platforms. | attribute structure to make it more flexible for non-unix platforms. | |||
o Clarify the use of stderr by the server. | o Clarify the use of stderr by the server. | |||
o Clarify handling of very large read requests by the server. | o Clarify handling of very large read requests by the server. | |||
o Make all filenames UTF-8. | o Make all filenames UTF-8. | |||
o Added 'newline' extension. | o Added 'newline' extension. | |||
o Made time fields 64 bit, and optionally have nanosecond resultion. | o Made time fields 64 bit, and optionally have nanosecond | |||
resolution. | ||||
o Made file attribute owner and group strings so they can actually | o Made file attribute owner and group strings so they can actually | |||
be used on disparate systems. | be used on disparate systems. | |||
o Added createtime field, and added separate flags for atime, | o Added createtime field, and added separate flags for atime, | |||
createtime, and mtime so they can be set separately. | createtime, and mtime so they can be set separately. | |||
o Split the file type out of the permissions field and into it's own | o Split the file type out of the permissions field and into its own | |||
field (which is always present.) | field (which is always present.) | |||
o Added acl attribute. | o Added acl attribute. | |||
o Added SSH_FXF_TEXT file open flag. | o Added SSH_FXF_TEXT file open flag. | |||
o Added flags field to the get stat commands so that the client can | o Added flags field to the get stat commands so that the client can | |||
specifically request information the server might not normally | specifically request information the server might not normally | |||
included for performance reasons. | included for performance reasons. | |||
o Removed the long filename from the names structure-- it can now be | o Removed the long filename from the names structure-- it can now be | |||
built from information available in the attrs structure. | built from information available in the attrs structure. | |||
o Added reserved range of packet numbers for extensions. | o Added reserved range of packet numbers for extensions. | |||
o Added several additional error codes. | o Added several additional error codes. | |||
10.2 Changes between versions 3 and 2 | 10.3 Changes Between Versions 3 and 2 | |||
o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added. | o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added. | |||
o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were | o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were | |||
added. | added. | |||
o The SSH_FXP_STATUS message was changed to include fields `error | o The SSH_FXP_STATUS message was changed to include fields 'error | |||
message' and `language tag'. | message' and 'language tag'. | |||
10.3 Changes between versions 2 and 1 | 10.4 Changes Between Versions 2 and 1 | |||
o The SSH_FXP_RENAME message was added. | o The SSH_FXP_RENAME message was added. | |||
10.4 Changes between versions 1 and 0 | 10.5 Changes Between Versions 1 and 0 | |||
o Implementation changes, no actual protocol changes. | o Implementation changes, no actual protocol changes. | |||
11. Trademark Issues | 11. Trademark Issues | |||
"ssh" is a registered trademark of SSH Communications Security Corp | "ssh" is a registered trademark of SSH Communications Security Corp | |||
in the United States and/or other countries. | in the United States and/or other countries. | |||
References | Normative References | |||
[1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and | ||||
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January | ||||
1999. | ||||
[2] Alvestrand, H., "IETF Policy on Character Sets and Languages", | ||||
BCP 18, RFC 2277, January 1998. | ||||
[3] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, | [1] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, | |||
C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC | C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC | |||
3010, December 2000. | 3010, December 2000. | |||
[4] Institute of Electrical and Electronics Engineers, "Information | [2] Institute of Electrical and Electronics Engineers, "Information | |||
Technology - Portable Operating System Interface (POSIX) - Part | Technology - Portable Operating System Interface (POSIX) - Part | |||
1: System Application Program Interface (API) [C Language]", | 1: System Application Program Interface (API) [C Language]", | |||
IEEE Standard 1003.2, 1996. | IEEE Standard 1003.2, 1996. | |||
[5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | [3] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | |||
Lehtinen, "SSH Protocol Architecture", | Lehtinen, "SSH Protocol Architecture", | |||
draft-ietf-secsh-architecture-13 (work in progress), September | draft-ietf-secsh-architecture-13 (work in progress), September | |||
2002. | 2002. | |||
[6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | [4] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | |||
Lehtinen, "SSH Protocol Transport Protocol", | Lehtinen, "SSH Protocol Transport Protocol", | |||
draft-ietf-secsh-transport-15 (work in progress), September | draft-ietf-secsh-transport-15 (work in progress), September | |||
2002. | 2002. | |||
[7] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | |||
Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16 | Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16 | |||
(work in progress), September 2002. | (work in progress), September 2002. | |||
Informative References | ||||
[6] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and | ||||
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January | ||||
1999. | ||||
[7] Alvestrand, H., "IETF Policy on Character Sets and Languages", | ||||
BCP 18, RFC 2277, January 1998. | ||||
[8] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | [8] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. | |||
Lehtinen, "SSH Authentication Protocol", | Lehtinen, "SSH Authentication Protocol", | |||
draft-ietf-secsh-userauth-16 (work in progress), September 2002. | draft-ietf-secsh-userauth-16 (work in progress), September 2002. | |||
Authors' Addresses | Authors' Addresses | |||
Joseph Galbraith | Joseph Galbraith | |||
VanDyke Software | VanDyke Software | |||
4848 Tramway Ridge Blvd | 4848 Tramway Ridge Blvd | |||
Suite 101 | Suite 101 | |||
skipping to change at page 37, line 29 | skipping to change at page 49, line 29 | |||
be obtained from the IETF Secretariat. | be obtained from the IETF Secretariat. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights which may cover technology that may be required to practice | rights which may cover technology that may be required to practice | |||
this standard. Please address the information to the IETF Executive | this standard. Please address the information to the IETF Executive | |||
Director. | Director. | |||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2002). All Rights Reserved. | Copyright (C) The Internet Society (2004). All Rights Reserved. | |||
This document and translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||
others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||
or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||
and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||
kind, provided that the above copyright notice and this paragraph are | kind, provided that the above copyright notice and this paragraph are | |||
included on all such copies and derivative works. However, this | included on all such copies and derivative works. However, this | |||
document itself may not be modified in any way, such as by removing | document itself may not be modified in any way, such as by removing | |||
the copyright notice or references to the Internet Society or other | the copyright notice or references to the Internet Society or other | |||
Internet organizations, except as needed for the purpose of | Internet organizations, except as needed for the purpose of | |||
skipping to change at page 38, line 7 | skipping to change at page 50, line 7 | |||
The limited permissions granted above are perpetual and will not be | The limited permissions granted above are perpetual and will not be | |||
revoked by the Internet Society or its successors or assignees. | revoked by the Internet Society or its successors or assignees. | |||
This document and the information contained herein is provided on an | This document and the information contained herein is provided on an | |||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
Acknowledgement | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
Internet Society. | Internet Society. | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |