draft-ietf-secsh-filexfer-06.txt   draft-ietf-secsh-filexfer-07.txt 
Secure Shell Working Group J. Galbraith Secure Shell Working Group J. Galbraith
Internet-Draft VanDyke Software Internet-Draft VanDyke Software
Expires: April 26, 2005 October 26, 2004 Expires: September 25, 2005 O. Saarenmaa
F-Secure
T. Ylonen
S. Lehtinen
SSH Communications Security Corp
March 24, 2005
SSH File Transfer Protocol SSH File Transfer Protocol
draft-ietf-secsh-filexfer-06.txt draft-ietf-secsh-filexfer-07.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 40
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://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 April 26, 2005. This Internet-Draft will expire on September 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use with the SSH Connection Protocol . . . . . . . . . . . . . 5 2. Use with the SSH Connection Protocol . . . . . . . . . . . . . 4
2.1 The Use of 'stderr' in the server . . . . . . . . . . . . 5 2.1 The Use of 'stderr' in the server . . . . . . . . . . . . 4
3. General Packet Format . . . . . . . . . . . . . . . . . . . . 6 3. General Packet Format . . . . . . . . . . . . . . . . . . . . 5
3.1 Request Synchronization and Reordering . . . . . . . . . . 6 3.1 Request Synchronization and Reordering . . . . . . . . . . 6
3.2 Packet Types . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 New data types defined by this document . . . . . . . . . 6
4. Protocol Initialization . . . . . . . . . . . . . . . . . . . 9 3.3 Packet Types . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Client Initialization . . . . . . . . . . . . . . . . . . 9 4. Protocol Initialization . . . . . . . . . . . . . . . . . . . 8
4.2 Server Initialization . . . . . . . . . . . . . . . . . . 9 4.1 Client Initialization . . . . . . . . . . . . . . . . . . 8
4.3 Determining Server Newline Convention . . . . . . . . . . 10 4.2 Server Initialization . . . . . . . . . . . . . . . . . . 8
4.4 Supported Features . . . . . . . . . . . . . . . . . . . . 11 4.3 Determining Server Newline Convention . . . . . . . . . . 9
4.5 Version re-negotiation . . . . . . . . . . . . . . . . . . 12 4.4 Supported Features . . . . . . . . . . . . . . . . . . . . 9
5. File Names . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5 Version re-negotiation . . . . . . . . . . . . . . . . . . 11
6. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 16 5. File Names . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1 valid-attribute-flags . . . . . . . . . . . . . . . . . . 16 6. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 13
6.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1 valid-attribute-flags . . . . . . . . . . . . . . . . . . 14
6.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4 AllocationSize . . . . . . . . . . . . . . . . . . . . . . 18 6.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.5 Owner and Group . . . . . . . . . . . . . . . . . . . . . 19 6.4 allocation-size . . . . . . . . . . . . . . . . . . . . . 16
6.6 Permissions . . . . . . . . . . . . . . . . . . . . . . . 19 6.5 Owner and Group . . . . . . . . . . . . . . . . . . . . . 16
6.7 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.6 Permissions . . . . . . . . . . . . . . . . . . . . . . . 17
6.8 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.7 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.9 attrib-bits . . . . . . . . . . . . . . . . . . . . . . . 21 6.8 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.10 Text Hint . . . . . . . . . . . . . . . . . . . . . . . . 24 6.9 attrib-bits . . . . . . . . . . . . . . . . . . . . . . . 19
6.11 Mime type . . . . . . . . . . . . . . . . . . . . . . . . 24 6.10 Text Hint . . . . . . . . . . . . . . . . . . . . . . . . 22
6.12 Link Count . . . . . . . . . . . . . . . . . . . . . . . . 24 6.11 Mime type . . . . . . . . . . . . . . . . . . . . . . . . 22
6.13 Extended Attributes . . . . . . . . . . . . . . . . . . . 24 6.12 Link Count . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Requests From the Client to the Server . . . . . . . . . . . . 26 6.13 Extended Attributes . . . . . . . . . . . . . . . . . . . 22
7.1 Opening and Closing Files and Directories . . . . . . . . 26 7. Requests From the Client to the Server . . . . . . . . . . . . 23
7.1.1 Opening a File . . . . . . . . . . . . . . . . . . . . 26 7.1 Opening and Closing Files and Directories . . . . . . . . 23
7.1.2 Opening a Directory . . . . . . . . . . . . . . . . . 30 7.1.1 Opening a File . . . . . . . . . . . . . . . . . . . . 23
7.1.3 Closing Handles . . . . . . . . . . . . . . . . . . . 30 7.1.2 Opening a Directory . . . . . . . . . . . . . . . . . 28
7.2 Reading and Writing . . . . . . . . . . . . . . . . . . . 31 7.1.3 Closing Handles . . . . . . . . . . . . . . . . . . . 29
7.2.1 Reading Files . . . . . . . . . . . . . . . . . . . . 31 7.2 Reading and Writing . . . . . . . . . . . . . . . . . . . 29
7.2.2 Reading Directories . . . . . . . . . . . . . . . . . 31 7.2.1 Reading Files . . . . . . . . . . . . . . . . . . . . 29
7.2.3 Writing Files . . . . . . . . . . . . . . . . . . . . 32 7.2.2 Reading Directories . . . . . . . . . . . . . . . . . 30
7.3 Removing and Renaming Files . . . . . . . . . . . . . . . 32 7.2.3 Writing Files . . . . . . . . . . . . . . . . . . . . 30
7.4 Creating and Deleting Directories . . . . . . . . . . . . 34 7.3 Removing and Renaming Files . . . . . . . . . . . . . . . 31
7.5 Retrieving File Attributes . . . . . . . . . . . . . . . . 34 7.4 Creating and Deleting Directories . . . . . . . . . . . . 32
7.6 Setting File Attributes . . . . . . . . . . . . . . . . . 35 7.5 Retrieving File Attributes . . . . . . . . . . . . . . . . 33
7.7 Dealing with Symbolic Links . . . . . . . . . . . . . . . 36 7.6 Setting File Attributes . . . . . . . . . . . . . . . . . 34
7.8 Canonicalizing the Server-Side Path Name . . . . . . . . . 37 7.7 Dealing with Links . . . . . . . . . . . . . . . . . . . . 35
7.8 Canonicalizing the Server-Side Path Name . . . . . . . . . 36
7.8.1 Best Practice for Dealing with Paths . . . . . . . . . 37 7.8.1 Best Practice for Dealing with Paths . . . . . . . . . 37
8. Responses from the Server to the Client . . . . . . . . . . . 39 8. Responses from the Server to the Client . . . . . . . . . . . 38
9. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1 Checking File Contents . . . . . . . . . . . . . . . . . . 45 9.1 File Hashing . . . . . . . . . . . . . . . . . . . . . . . 45
9.2 Querying Available Space . . . . . . . . . . . . . . . . . 46 9.1.1 Checking File Contents: v5 extension . . . . . . . . . 46
10. Implementation Considerations . . . . . . . . . . . . . . . 48 9.1.2 Checking File Contents . . . . . . . . . . . . . . . . 47
11. Security Considerations . . . . . . . . . . . . . . . . . . 49 9.2 Querying Available Space . . . . . . . . . . . . . . . . . 48
12. Changes from Previous Protocol Versions . . . . . . . . . . 51 9.3 Querying User Home Directory . . . . . . . . . . . . . . . 49
12.1 Changes Between Versions 6 and 5 . . . . . . . . . . . . . 51 10. Implementation Considerations . . . . . . . . . . . . . . . 50
12.2 Changes Between Versions 5 and 4 . . . . . . . . . . . . . 51 11. Security Considerations . . . . . . . . . . . . . . . . . . 50
12.3 Changes Between Versions 4 and 3 . . . . . . . . . . . . . 52 12. Changes from Previous Protocol Versions . . . . . . . . . . 52
12.4 Changes Between Versions 3 and 2 . . . . . . . . . . . . . 52 12.1 Changes Between Versions 6 and 5 . . . . . . . . . . . . . 52
12.5 Changes Between Versions 2 and 1 . . . . . . . . . . . . . 52 12.2 Changes Between Versions 5 and 4 . . . . . . . . . . . . . 52
12.6 Changes Between Versions 1 and 0 . . . . . . . . . . . . . 53 12.3 Changes Between Versions 4 and 3 . . . . . . . . . . . . . 53
12.4 Changes Between Versions 3 and 2 . . . . . . . . . . . . . 54
12.5 Changes Between Versions 2 and 1 . . . . . . . . . . . . . 54
12.6 Changes Between Versions 1 and 0 . . . . . . . . . . . . . 54
13. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . 54 13. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . 54
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
14.1 Normative References . . . . . . . . . . . . . . . . . . . . 55 14.1 Normative References . . . . . . . . . . . . . . . . . . . 54
14.2 Informative References . . . . . . . . . . . . . . . . . . . 55 14.2 Informative References . . . . . . . . . . . . . . . . . . 55
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . . 57 Intellectual Property and Copyright Statements . . . . . . . . 57
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.) It is designed so that it could be used to implement system access.) It is designed so that it could be used to implement
a secure remote file system service, as well as a secure file a secure remote file system service, as well as a secure file
transfer service. transfer service.
This protocol assumes that it runs over a secure channel, such as a This protocol assumes that it runs over a secure channel, such as a
channel in the SSH2 protocol [1]. and that the server has already channel in [I-D.ietf-secsh-architecture]. and that the server has
authenticated the client, and that the identity of the client user is already authenticated the client, and that the identity of the client
available to the protocol. user is 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. [1] notation presented in [I-D.ietf-secsh-architecture].
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 [7] and applications, such as secure file transfer over TLS [RFC2246] 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 [3] as a subsystem, as be used as a subsystem as described in [I-D.ietf-secsh-connect] in
described in section ''Starting a Shell or a Command''. The the section "Starting a Shell or a Command". The subsystem name used
subsystem name used with this protocol is "sftp". with this protocol is "sftp".
2.1 The Use of 'stderr' in the server 2.1 The Use of 'stderr' in the server
This protocol uses stdout and stdin to transmit binary protocol data. This protocol uses stdout and stdin to transmit binary protocol data.
The "session" channel SSH Connection Protocol [3], which is used by The "session" channel ([I-D.ietf-secsh-connect]), which is used by
the subsystem, also supports the use of stderr. the subsystem, also supports the use of stderr.
Data sent on stderr by the server SHOULD be considered free format Data sent on stderr by the server SHOULD be considered free format
debug or supplemental error information, and MAY be displayed to the debug or supplemental error information, and MAY be displayed to the
user. user.
For example, during initialization, there is no client request For example, during initialization, there is no client request
active, so errors or warning information cannot be sent to the client active, so errors or warning information cannot be sent to the client
as part of the SFTP protocol at this early stage. However, the as part of the SFTP protocol at this early stage. However, the
errors or warnings MAY be sent as stderr text. 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
uint32 request-id uint32 request-id
... type specific fields... ... type specific fields...
byte[length] data payload
'length' is the length of the entire packet, excluding the length 'length'
field itself, such that, for example, for a packet type containing no The length of the entire packet, excluding the length field
itself, such that, for example, for a packet type containing no
type specific fields, the length field would be 5, and 9 bytes of type specific fields, the length field would be 5, and 9 bytes of
data would be sent on the wire. (This is the packet format used in data would be sent on the wire. (This is the packet format used
the secsh transport. [2] in [I-D.ietf-secsh-transport].)
All packet descriptions in this document omit the length field for All packet descriptions in this document omit the length field for
brevity; the length field MUST be included in any case. brevity; the length field MUST be included in any case.
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 bytes of packet overhead). All servers SHOULD support
packets of at least 34000 bytes (where the packet size refers to
the full length, including the header above). This should allow
for reads and writes of at most 32768 bytes.
'type'
The type code for the packet.
'request-id'
Each request from the client contains a 'request-id' field. Each Each request from the client contains a 'request-id' field. Each
response from the server includes that same 'request-id' from the response from the server includes that same 'request-id' from the
request that the server is responding to. One possible request that the server is responding to. One possible
implementation is for the client to us a monotonically increasing implementation is for the client to us a monotonically increasing
request sequence number (modulo 2^32). There is, however, no request sequence number (modulo 2^32). There is, however, no
particular requirement the 'request-id' fields be unique. particular requirement the 'request-id' fields be unique.
There are two packets, INIT and VERSION, which do not use the
request-id.
Packet descriptions in this document will contain the 'request-id'
field, but will not redefine it.
Implementations MUST ignore excess data after an otherwise valid
packet. Implementation MUST respond to unrecognized packet types
with an SSH_FX_OP_UNSUPPORTED error. This will allow the protocol to
be extended in a backwards compatible way as needed.
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.
skipping to change at page 7, line 17 skipping to change at page 6, line 42
There are no restrictions on the order in which responses to There are no restrictions on the order in which responses to
outstanding requests are delivered to the client, except that the outstanding requests are delivered to the client, except that the
server must ensure fairness in the sense that processing of no server must ensure fairness in the sense that processing of no
request will be indefinitely delayed even if the client is sending request will be indefinitely delayed even if the client is sending
other requests so that there are multiple outstanding requests all other requests so that there are multiple outstanding requests all
the time. the time.
A client MUST be prepared to recieve responses to multiple overlapped A client MUST be prepared to recieve responses to multiple overlapped
requests out of order. requests out of order.
This document defines one data type in addition to those defined in 3.2 New data types defined by this document
secsh architecture draft. [1]
This document defines several data types in addition to those defined
in [I-D.ietf-secsh-architecture].
int64 int64
Represents a 64-bit signed integer. Stored as eight bytes in the Represents a 64-bit signed integer. Stored as eight bytes in the
order of decreasing significance (network byte order). order of decreasing significance (network byte order).
The maximum size of a packet is in practice determined by the client extension-pair
(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
least 34000 bytes (where the packet size refers to the full length,
including the header above). This should allow for reads and writes
of at most 32768 bytes.
3.2 Packet Types string extension-name
string extension-data
The following values are defined for packet types. 'extension-name' is the name of a protocol extension. Extensions
not defined by IETF consensus MUST follow the the DNS
extensibility naming convention outlined in
[I-D.ietf-secsh-architecture].
#define SSH_FXP_INIT 1 'extension-data' is any data specific to the extension, and MAY be
#define SSH_FXP_VERSION 2 zero length if the extension has no data.
#define SSH_FXP_OPEN 3
#define SSH_FXP_CLOSE 4
#define SSH_FXP_READ 5
#define SSH_FXP_WRITE 6
#define SSH_FXP_LSTAT 7
#define SSH_FXP_FSTAT 8
#define SSH_FXP_SETSTAT 9
#define SSH_FXP_FSETSTAT 10
#define SSH_FXP_OPENDIR 11
#define SSH_FXP_READDIR 12
#define SSH_FXP_REMOVE 13
#define SSH_FXP_MKDIR 14
#define SSH_FXP_RMDIR 15
#define SSH_FXP_REALPATH 16
#define SSH_FXP_STAT 17
#define SSH_FXP_RENAME 18
#define SSH_FXP_READLINK 19
#define SSH_FXP_SYMLINK 20
#define SSH_FXP_STATUS 101 3.3 Packet Types
#define SSH_FXP_HANDLE 102
#define SSH_FXP_DATA 103
#define SSH_FXP_NAME 104
#define SSH_FXP_ATTRS 105
#define SSH_FXP_EXTENDED 200 The following values are defined for packet types.
#define SSH_FXP_EXTENDED_REPLY 201
SSH_FXP_INIT 1
SSH_FXP_VERSION 2
SSH_FXP_OPEN 3
SSH_FXP_CLOSE 4
SSH_FXP_READ 5
SSH_FXP_WRITE 6
SSH_FXP_LSTAT 7
SSH_FXP_FSTAT 8
SSH_FXP_SETSTAT 9
SSH_FXP_FSETSTAT 10
SSH_FXP_OPENDIR 11
SSH_FXP_READDIR 12
SSH_FXP_REMOVE 13
SSH_FXP_MKDIR 14
SSH_FXP_RMDIR 15
SSH_FXP_REALPATH 16
SSH_FXP_STAT 17
SSH_FXP_RENAME 18
SSH_FXP_READLINK 19
SSH_FXP_LINK 21
SSH_FXP_STATUS 101
SSH_FXP_HANDLE 102
SSH_FXP_DATA 103
SSH_FXP_NAME 104
SSH_FXP_ATTRS 105
SSH_FXP_EXTENDED 200
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 extensions, which can be vendor packets can be used to implement extensions, which can be vendor
specific. See Section ''Extensions'' for more details. specific. See Section ''Extensions'' for more details.
4. Protocol Initialization 4. Protocol Initialization
skipping to change at page 9, line 17 skipping to change at page 8, line 25
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 server responds with a SSH_FXP_VERSION packet, supplying the The server responds with a SSH_FXP_VERSION packet, supplying the
lowest of its own and the client's version number. Both parties lowest of its own and the client's version number. Both parties
should from then on adhere to particular version of the protocol. should from then on adhere to particular version of the protocol.
The version number of the protocol specified in this document is 6. The version number of the protocol specified in this document is 6.
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.
********************* DO NOT IMPLEMENT *********************** Note that these two packets DO NOT contain a request id. These are
********************* DO NOT IMPLEMENT *********************** the only such packets in the protocol.
***** *****
***** There will be more edits after IETF 61. *****
***** *****
********************* DO NOT IMPLEMENT ***********************
********************* DO NOT IMPLEMENT ***********************
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
Version 3 of this protocol allowed clients to include extensions in 'version' is the version number of the client. If the client wishes
the SSH_FXP_INIT packet; however, this can cause interoperability to interoperate with servers that support dis-contigous version
problems with version 1 and version 2 servers because the client must numbers it SHOULD send '3', and then use the 'version-select'
send this packet before knowing the servers version. extension (see below.) Otherwise, this value is '6' for this version
of the protocol.
In this version of the protocol, clients MUST use the
SSH_FXP_EXTENDED packet to send extensions to the server after
version exchange has completed. Clients MUST NOT include extensions
in the version packet. This will prevent interoperability problems
with older servers
4.2 Server Initialization 4.2 Server Initialization
The SSH_FXP_VERSION packet (from server to client) has the following The SSH_FXP_VERSION packet (from server to client) has the following
data: data:
uint32 version uint32 version
<extension data> extension-pair extensions[0..n]
'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 'extensions' is 0 or more extension-pairs (Section 3.2).
string extension_name
string extension_data
pairs (both strings MUST always be present if one is, but the
'extension_data' string may be of zero length). If present, these
strings indicate extensions to the baseline protocol. 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
domain name of the organization defining the extension. Additional
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, newline sequences must be converted between client compatible way, newline sequences must be converted between client
and server conventions. and server conventions.
The SSH_FXF_TEXT file open flag (Section 7.1.1) makes it possible to The SSH_FXF_TEXT file open flag (Section 7.1.1) makes it possible to
request that the server translate a file to a 'canonical' wire request that the server translate a file to a 'canonical' wire
format. This format uses \r\n as the line separator. format. This format uses \r\n as the line 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 server's character or sequence that is not an exact match of the server's
newline separator. newline separator.
skipping to change at page 11, line 15 skipping to change at page 9, line 50
4.4 Supported Features 4.4 Supported Features
The sftp protocol has grown to be very rich, and now supports a The sftp protocol has grown to be very rich, and now supports a
number of features that may not be available on all servers. number of features that may not be available on all servers.
When a server receives a request for a feature it cannot support, it When a server receives a request for a feature it cannot support, it
MUST return a SSH_FX_OP_UNSUPPORTED status code, unless otherwise MUST return a SSH_FX_OP_UNSUPPORTED status code, unless otherwise
specified. In order to facilitate clients being able to use the specified. In order to facilitate clients being able to use the
maximum available feature set, and yet not be overly burdened by maximum available feature set, and yet not be overly burdened by
dealing with SSH_FX_OP_UNSUPPORTED status codes, the following dealing with SSH_FX_OP_UNSUPPORTED status codes, the following
extension is introduced. extension which all servers MUST include as part of their version
packet, is introduced.
string "supported" string "supported2"
string supported-structure string supported-structure
uint32 supported-attribute-mask uint32 supported-attribute-mask
uint32 supported-attribute-bits uint32 supported-attribute-bits
uint32 supported-open-flags uint32 supported-open-flags
uint32 supported-access-mask
uint32 max-read-size uint32 max-read-size
string extension-names[0..n] string extension-names[0..n]
supported-attribute-mask supported-attribute-mask
This mask MAY by applied to the 'File Attributes' This mask MAY by applied to the 'File Attributes'
valid-attribute-flags field (Section 6.1) to ensure that no valid-attribute-flags field (Section 6.1) to ensure that no
unsupported attributes are present during a operation which writes unsupported attributes are present during a operation which writes
attributes. attributes.
supported-attribute-bits supported-attribute-bits
This mask MAY by applied to the 'File Attributes' attrib-bits This mask MAY by applied to the 'File Attributes' attrib-bits
field (Section 6.9) to ensure that no unsupported attrib-bits are field (Section 6.9) to ensure that no unsupported attrib-bits are
present during a operation which writes attributes. present during a operation which writes attributes.
supported-open-flags supported-open-flags
The supported-open-flags mask MAY be applied to the SSH_FXP_OPEN The supported-open-flags mask MAY be applied to the SSH_FXP_OPEN
(Section 7.1.1) flags field. (Section 7.1.1) flags field.
supported-access-mask
The supported-access-mask mask MAY be applied to the SSH_FXP_OPEN
(Section 7.1.1) desired-access field or the ace-mask field of an
ACL.
max-read-size max-read-size
This is the maximum read size that the server gaurantees to This is the maximum read size that the server gaurantees to
complete. For example, certain embedded server implementations complete. For example, certain embedded server implementations
only complete the first 4K of a read, even if there is additional only complete the first 4K of a read, even if there is additional
data to be read from the file. data to be read from the file.
If the server specifies a non-zero value, it MUST return at least If the server specifies a non-zero value, it MUST return at least
the max-read-size number of bytes for any read requesting the max-read-size number of bytes for any read requesting
max-read-size bytes. Failure to return max-read-size bytes in max-read-size bytes. Failure to return max-read-size bytes in
such a case indicates either EOF or another error condition such a case indicates either EOF or another error condition
skipping to change at page 12, line 34 skipping to change at page 11, line 15
The client MAY send requests that are not supported by 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 however, it is not normally expected to be productive to do so. The
client SHOULD apply the mask even to attrib structures received from client SHOULD apply the mask even to attrib structures received from
the server. The server MAY include attributes or attrib-bits that the server. The server MAY include attributes or attrib-bits that
are not included in the mask. Such attributes or attrib-bits are are not included in the mask. Such attributes or attrib-bits are
effectively read-only. effectively read-only.
4.5 Version re-negotiation 4.5 Version re-negotiation
The version exchange during protocol startup forces an implementation If the server supports a higher version than was negotiated, it may
to support all versions up to it's highest supported version; wish to send the 'versions' extension to inform the client of this
however, there have been a number of SFTP protocol versions deployed, fact. The client may then optionally choose to use one of the higher
and it is supposed that more implementations will support the final versions supported.
version of this protocol if they don't have to support all versions
between their currently deployed version and the final version.
Furthermore, only the current version of this protocol is documented,
so supporting earlier versions becomes problematic.
Therefore, the server SHOULD send the following extension as part of
it's INIT packet to inform the client of the versions it supports.
string "versions" string "versions"
string comma-seperated-versions string comma-seperated-versions
'comma-seperated-versions' is a string of comma seperated version 'comma-seperated-versions' is a string of comma seperated version
numbers, for example, "3,6,7" numbers, for example, "3,6,7. Versions defined by are: "2", "3",
A client wishing to support two non-continigous version of the "4", "5", "6". Any other version advertised by the server must
protocol must negotiate the lowest version for which it supports all follow the DNS extensibility naming convention outlined in
previous versions. When the client recieves the servers INIT packet, [I-D.ietf-secsh-architecture].
if it includes the "versions" extension, it MAY send the following
extended request:
byte SSH_FXP_EXTENDED The client may select a new version to use from the list the server
uint32 request-id provided using the following SSH_FXP_EXTENDED request.
string "version"
string "version-select"
uint32 version-from-list uint32 version-from-list
If the 'version-from-list' is one of the versions on the servers If the 'version-from-list' is one of the versions on the servers
list, the server MUST respond with SSH_FX_OK. If the server did not list, the server MUST respond with SSH_FX_OK. If the server did not
send the "versions" extension, or the version-from-list was not send the "versions" extension, or the version-from-list was not
included, the server MAY send a status response describing the included, the server MAY send a status response describing the
failure, but MUST then close the channel. failure, but MUST then close the channel without processing any
further requests.
Although this request does take a full round trip, no client need Although this request does take a full round trip, no client need
wait for the response before continuing, because any valid request wait for the response before continuing, because any valid request
MUST succeed. MUST succeed, and any invalid request results in a channel close.
5. File Names 5. File Names
This protocol represents file names as strings. File names are This protocol represents file names as strings. File names are
assumed to use the slash ('/') character as a directory separator. assumed to use the slash ('/') character as a directory separator.
File names starting with a slash are "absolute", and are relative to File names starting with a slash are "absolute", and are relative to
the root of the file system. Names starting with any other character the root of the file system. Names starting with any other character
are relative to the user's default directory (home directory). Note are relative to the user's default directory (home directory). Note
that identifying the user is assumed to take place outside of this that identifying the user is assumed to take place outside of this
skipping to change at page 14, line 36 skipping to change at page 12, line 29
using a slash ('/') as the separator, and that will work as expected. using a slash ('/') as the separator, and that will work as expected.
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.
The prefered encoding for filenames is UTF-8. This is consistant The prefered encoding for filenames is UTF-8. This is consistant
with IETF Policy on Character Sets and Languages [8] and it is with IETF Policy on Character Sets and Languages [RFC2277] and it is
further supposed that the server is more likely to support any local further supposed that the server is more likely to support any local
character set and be able to convert it to UTF-8. character set and be able to convert it to UTF-8.
The shortest valid UTF-8 encoding of the UNICODE data MUST be used.
The server is responsible for converting the UNICODE data to whatever
canonical form it requires. For example, if the server requires that
precomposed characters always be used, the server MUST NOT assume the
filename as sent by the client has this attribute, but must do this
normalization itself.
However, because the server does not always know the encoding of However, because the server does not always know the encoding of
filenames, it is not always possible for the server to preform a filenames, it is not always possible for the server to preform a
valid translation to UTF-8. When an invalid translation to UTF-8 is valid translation to UTF-8. When an invalid translation to UTF-8 is
preformed, it becomes impossible to manipulate the file, because the preformed, it becomes impossible to manipulate the file, because the
translation is not reversable. Therefore, the following extensions translation is not reversable. Therefore, the following extensions
are provided in order to make it possible for the server to are provided in order to make it possible for the server to
communicate it's abilities to the client, and to allow the client to communicate it's abilities to the client, and to allow the client to
control whether the server attempts the conversion. control whether the server attempts the conversion.
A server MAY include the following extension with it's version A server MAY include the following extension with it's version
packet. packet.
string "filename-charset" string "filename-charset"
string charset-name string charset-name
A server that can always provide a valid UTF-8 translation for A server that can always provide a valid UTF-8 translation for
filenames SHOULD NOT send this extension. Otherwise, the server filenames SHOULD NOT send this extension. Otherwise, the server
SHOULD this extension and include the encoding most likely to be used SHOULD send this extension and include the encoding most likely to be
for filenames. This value will most likely be derived from the used for filenames. This value will most likely be derived from the
LC_CTYPE on most unix-like systems. LC_CTYPE on most unix-like systems.
A server that does not send this extension MUST send all filenames A server that does not send this extension MUST send all filenames
encoded in UTF-8. All clients MUST support UTF-8 filenames. encoded in UTF-8. All clients MUST support UTF-8 filenames.
If the server included the 'filename-charset' extension with its If the server included the 'filename-charset' extension with its
VERSION packet, a client MAY send the following extension to turn off VERSION packet, a client MAY send the following extension to turn off
server translation to UTF-8. server translation to UTF-8.
string "filename-translation-control" string "filename-translation-control"
skipping to change at page 16, line 5 skipping to change at page 13, line 25
If the client does not send this extension, the server MUST continue If the client does not send this extension, the server MUST continue
to attempt translation to UTF-8. When a client sends this extension, to attempt translation to UTF-8. When a client sends this extension,
the server MUST enable or disable filename translation according to the server MUST enable or disable filename translation according to
the value of 'do-translate' the value of 'do-translate'
The server MUST respond with a STATUS response; if the server sent a The server MUST respond with a STATUS response; if the server sent a
'filename-charset' extension, the status MUST be SUCCESS. Otherwise, 'filename-charset' extension, the status MUST be SUCCESS. Otherwise,
the status MUST be UNSUPPORTED. the status MUST be UNSUPPORTED.
When UTF-8 is sent, the shortest valid UTF-8 encoding of the UNICODE
data MUST be used. The server is responsible for converting the
UNICODE data to whatever canonical form it requires. For example, if
the server requires that precomposed characters always be used, the
server MUST NOT assume the filename as sent by the client has this
attribute, but must do this normalization itself.
6. File Attributes 6. 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 same encoding is used both when returning file attributes from The same encoding is used both when returning file attributes from
the server and when sending file attributes to the server. the server and when sending file attributes to the server.
uint32 valid-attribute-flags uint32 valid-attribute-flags
byte type always present byte type always present
uint64 size present only if flag SIZE uint64 size if flag SIZE
uint64 allocation-size present only if flag ALLOCATION_SIZE uint64 allocation-size if flag ALLOCATION_SIZE
string owner present only if flag OWNERGROUP string owner if flag OWNERGROUP
string group present only if flag OWNERGROUP string group if flag OWNERGROUP
uint32 permissions present only if flag PERMISSIONS uint32 permissions if flag PERMISSIONS
int64 atime present only if flag ACCESSTIME int64 atime if flag ACCESSTIME
uint32 atime_nseconds present only if flag SUBSECOND_TIMES uint32 atime_nseconds if flag SUBSECOND_TIMES
int64 createtime present only if flag CREATETIME int64 createtime if flag CREATETIME
uint32 createtime_nseconds present only if flag SUBSECOND_TIMES uint32 createtime_nseconds if flag SUBSECOND_TIMES
int64 mtime present only if flag MODIFYTIME int64 mtime if flag MODIFYTIME
uint32 mtime_nseconds present only if flag SUBSECOND_TIMES uint32 mtime_nseconds if flag SUBSECOND_TIMES
string acl present only if flag ACL string acl if flag ACL
uint32 attrib-bits present only if flag BITS uint32 attrib-bits if flag BITS
byte text-hint present only if flag TEXT_HINT byte text-hint if flag TEXT_HINT
string mime-type present only if flag MIME_TYPE string mime-type if flag MIME_TYPE
uint32 link-count present only if flag LINK_COUNT uint32 link-count if flag LINK_COUNT
string untranslated-name present only if flag UNTRANSLATED_NAME string untranslated-name if flag UNTRANSLATED_NAME
uint32 extended_count present only if flag EXTENDED uint32 extended_count if flag EXTENDED
string extended_type extended-pair extensions
string extended_data
... more extended data (extended_type - extended_data pairs),
so that number of pairs equals extended_count
6.1 valid-attribute-flags 6.1 valid-attribute-flags
The 'valid-attribute-flags' specifies which of the fields are The 'valid-attribute-flags' specifies which of the fields are
present. Those fields for which the corresponding flag is not set present. Those fields for which the corresponding flag is not set
are not present (not included in the packet). are not present (not included in the packet).
The server generally includes all attributes it knows about; however, The server generally includes all attributes it knows about; however,
it may exclude attributes that are overly expensive to retrieve it may exclude attributes that are overly expensive to retrieve
unless the client explicitly requests them. unless the client explicitly requests them.
skipping to change at page 17, line 4 skipping to change at page 14, line 43
The server generally includes all attributes it knows about; however, The server generally includes all attributes it knows about; however,
it may exclude attributes that are overly expensive to retrieve it may exclude attributes that are overly expensive to retrieve
unless the client explicitly requests them. unless the client explicitly requests them.
When writing attributes, the server SHOULD NOT modify attributes that When writing attributes, the server SHOULD NOT modify attributes that
are not present in the structure. However, if necessary, the server are not present in the structure. However, if necessary, the server
MAY use a default value for an absent attribute. MAY use a default value for an absent attribute.
In general, unless otherwise specified, if a server cannot support In general, unless otherwise specified, if a server cannot support
writing an attribute requested, it must fail the setstat operation. writing an attribute requested, it must fail the setstat operation.
In this case, none of the attributes SHOULD be changed. In this case, none of the attributes SHOULD be changed.
New fields can only be added by incrementing the protocol version New fields can only be added by incrementing the protocol version
number (or by using the extension mechanism described below). number (or by using the extension mechanism described below).
The following values are defined: The following values are defined:
#define SSH_FILEXFER_ATTR_SIZE 0x00000001 SSH_FILEXFER_ATTR_SIZE 0x00000001
#define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004 SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004
#define SSH_FILEXFER_ATTR_ACCESSTIME 0x00000008 SSH_FILEXFER_ATTR_ACCESSTIME 0x00000008
#define SSH_FILEXFER_ATTR_CREATETIME 0x00000010 SSH_FILEXFER_ATTR_CREATETIME 0x00000010
#define SSH_FILEXFER_ATTR_MODIFYTIME 0x00000020 SSH_FILEXFER_ATTR_MODIFYTIME 0x00000020
#define SSH_FILEXFER_ATTR_ACL 0x00000040 SSH_FILEXFER_ATTR_ACL 0x00000040
#define SSH_FILEXFER_ATTR_OWNERGROUP 0x00000080 SSH_FILEXFER_ATTR_OWNERGROUP 0x00000080
#define SSH_FILEXFER_ATTR_SUBSECOND_TIMES 0x00000100 SSH_FILEXFER_ATTR_SUBSECOND_TIMES 0x00000100
#define SSH_FILEXFER_ATTR_BITS 0x00000200 SSH_FILEXFER_ATTR_BITS 0x00000200
#define SSH_FILEXFER_ATTR_ALLOCATION_SIZE 0x00000400 SSH_FILEXFER_ATTR_ALLOCATION_SIZE 0x00000400
#define SSH_FILEXFER_ATTR_TEXT_HINT 0x00000800 SSH_FILEXFER_ATTR_TEXT_HINT 0x00000800
#define SSH_FILEXFER_ATTR_MIME_TYPE 0x00001000 SSH_FILEXFER_ATTR_MIME_TYPE 0x00001000
#define SSH_FILEXFER_ATTR_LINK_COUNT 0x00002000 SSH_FILEXFER_ATTR_LINK_COUNT 0x00002000
#define SSH_FILEXFER_ATTR_UNTRANLATED_NAME 0x00004000 SSH_FILEXFER_ATTR_UNTRANSLATED_NAME 0x00004000
#define SSH_FILEXFER_ATTR_EXTENDED 0x80000000 SSH_FILEXFER_ATTR_EXTENDED 0x80000000
0x00000002 was used in a previous version of this protocol. It is 0x00000002 was used in a previous version of this protocol. It is
now a reserved value and MUST NOT appear in the mask. Some future now a reserved value and MUST NOT appear in the mask. Some future
version of this protocol may reuse this value. version of this protocol may reuse this value.
6.2 Type 6.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 SSH_FILEXFER_TYPE_REGULAR 1
#define SSH_FILEXFER_TYPE_DIRECTORY 2 SSH_FILEXFER_TYPE_DIRECTORY 2
#define SSH_FILEXFER_TYPE_SYMLINK 3 SSH_FILEXFER_TYPE_SYMLINK 3
#define SSH_FILEXFER_TYPE_SPECIAL 4 SSH_FILEXFER_TYPE_SPECIAL 4
#define SSH_FILEXFER_TYPE_UNKNOWN 5 SSH_FILEXFER_TYPE_UNKNOWN 5
#define SSH_FILEXFER_TYPE_SOCKET 6 SSH_FILEXFER_TYPE_SOCKET 6
#define SSH_FILEXFER_TYPE_CHAR_DEVICE 7 SSH_FILEXFER_TYPE_CHAR_DEVICE 7
#define SSH_FILEXFER_TYPE_BLOCK_DEVICE 8 SSH_FILEXFER_TYPE_BLOCK_DEVICE 8
#define SSH_FILEXFER_TYPE_FIFO 9 SSH_FILEXFER_TYPE_FIFO 9
On a POSIX system, these values would be derived from the mode field On a POSIX system, these values would be derived from the mode field
of the stat structure. SPECIAL should be used for files that are of of the stat structure. SPECIAL should be used for files that are of
a known type which cannot be expressed in the protocol. UNKNOWN a known type which cannot be expressed in the protocol. UNKNOWN
should be used if the type is not known. should be used if the type is not known.
6.3 Size 6.3 Size
The 'size' field specifies the number of bytes that can be read from The 'size' field specifies the number of bytes that can be read from
the file, or in other words, the location of the end-of-file. If it the file, or in other words, the location of the end-of-file. This
is present during file creation, the file MUST be created and then attribute MUST NOT be present during file creation.
the EOF set to 'size'. A read from such a file SHOULD return nul
bytes, but this is not required if the underlying filesystem has
different characteristics.
If this field is present during a setstat operation, the file MUST be If this field is present during a setstat operation, the file MUST be
extended or truncated to the specified size. Clients SHOULD extended or truncated to the specified size.
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_ACCESS_TEXT flag may have a size that
greater or less than the value of the size field. is greater or less than the value of the size field. The server MAY
fail setstat operations specifying size for files opened with the
SSH_FXF_ACCESS_TEXT flag.
6.4 AllocationSize 6.4 allocation-size
The 'allocation-size' field specifies the number of bytes that the The 'allocation-size' field specifies the number of bytes that the
file consumes on disk. This is normally greater than or equal to the file consumes on disk. This is greater than or equal to the 'size'
'size' field. If it is present during file creation, it should be field.
treated as a hint as to the eventual file size. The server MAY
choose to preallocate the disk space to save the overhead of repeated
extends. However, the file size MUST NOT be set to this value. In
other words, a read from such a file MUST fail with an EOF error.
(Unless 'size' was also set.)
If the server is unable to honor this hint during create, the create When present during file creation, the file SHOULD be created and the
should succeed regardless. Because this field is a hint, the field specified number of bytes pre-allocated. If the pre-allocation
may be specified even if the server doesn't set the bit in it's fails, the file should be removed and an error returned.
supported-attribute-mask.
If this field is present during a setstat operation, the file SHOULD If this field is present during a setstat operation, the file SHOULD
be extended or truncated to the specified size. Clients SHOULD be extended or truncated to the specified size. The 'size' of the
therefore be careful specifying size during a setstat operation. file may be affected by this operation. If the operation succeeds,
it should be the min of the 'size' before the operation and the new
If the file is extended by this operation, 'size' MUST not be 'allocation-size'.
affected. If the file is truncated by this operation, 'size' will be
changed ot match the new file allocation.
If a server can not honor the setstat operation, it MUST NOT set Querying the 'allocation-size' after setting it MUST return a value
allocation-size in it's supported-attribute-mask, though it MAY still that is greater-than or equal to the value set, but it MAY not return
send the allocation-size data if it can retrieve it. In addition, the precise value set.
such a server MUST fail a setstat operaiton that has the
allocation-size field present.
6.5 Owner and Group 6.5 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 [4]. The is the form used by NFS v4. See NFS version 4 Protocol [RFC3010].
following text is selected quotations from section 5.6. The 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 will allow for a client and server that do not use the same This will allow for a client and server that do not use the same
local representation the ability to translate to a common syntax that local representation the ability to translate to a common syntax that
can be interpreted by both. In the case where there is no can be interpreted by both. In the case where there is no
translation available to the client or server, the attribute value translation available to the client or server, the attribute value
must be constructed without the "@". Therefore, the absence of the @ must be constructed without the "@". Therefore, the absence of the @
from the owner or owner_group attribute signifies that no translation from the owner or owner_group attribute signifies that no translation
skipping to change at page 19, line 36 skipping to change at page 17, line 13
user@localhost represents a user in the context of the server. user@localhost represents a user in the context of the server.
If either the owner or group field is zero length, the field should 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 be considered absent, and no change should be made to that specific
field. field.
6.6 Permissions 6.6 Permissions
The 'permissions' field contains a bit mask specifying file The 'permissions' field contains a bit mask specifying file
permissions. These permissions correspond to the st_mode field of permissions. These permissions correspond to the st_mode field of
the stat structure defined by POSIX [5]. the stat structure defined by POSIX [IEEE.1003-1.1996].
This protocol uses the following values for the symbols declared in This protocol uses the following values for the symbols declared in
the posix standard. the posix standard.
#define S_IRUSR 0000400 (octal) S_IRUSR 0000400 (octal)
#define S_IWUSR 0000200 S_IWUSR 0000200
#define S_IXUSR 0000100 S_IXUSR 0000100
#define S_IRGRP 0000040 S_IRGRP 0000040
#define S_IWGRP 0000020 S_IWGRP 0000020
#define S_IXGRP 0000010 S_IXGRP 0000010
#define S_IROTH 0000004 S_IROTH 0000004
#define S_IWOTH 0000002 S_IWOTH 0000002
#define S_IXOTH 0000001 S_IXOTH 0000001
#define S_ISUID 0004000 S_ISUID 0004000
#define S_ISGID 0002000 S_ISGID 0002000
#define S_ISVTX 0001000 S_ISVTX 0001000
Implementations MUST NOT send bits that are not defined. Implementations MUST NOT send bits that are not defined.
The server SHOULD NOT apply a 'umask' to the mode bits; but should
set the mode bits as specified by the client. The client MUST apply
an appropriate 'umask' to the mode bits before sending them.
6.7 Times 6.7 Times
The 'atime', 'createtime', and 'mtime' contain the accesses, The 'atime', 'createtime', and 'mtime' contain the access, creation,
creation, and modification times of the files, respectively. They and modification times of the files, respectively. They are
are represented as seconds from Jan 1, 1970 in UTC. 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.
6.8 ACL 6.8 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 [4]. 5.9 of NFS version 4 Protocol [RFC3010].
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 [4]: 4 Protocol [RFC3010]:
#define ACE4_ACCESS_ALLOWED_ACE_TYPE 0x00000000; ACE4_ACCESS_ALLOWED_ACE_TYPE 0x00000000
#define ACE4_ACCESS_DENIED_ACE_TYPE 0x00000001; ACE4_ACCESS_DENIED_ACE_TYPE 0x00000001
#define ACE4_SYSTEM_AUDIT_ACE_TYPE 0x00000002; ACE4_SYSTEM_AUDIT_ACE_TYPE 0x00000002
#define ACE4_SYSTEM_ALARM_ACE_TYPE 0x00000003; 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 [4] section 5.9.2: Version 4 Protocol [RFC3010] section 5.9.2:
ACE4_FILE_INHERIT_ACE 0x00000001
ACE4_DIRECTORY_INHERIT_ACE 0x00000002
ACE4_NO_PROPAGATE_INHERIT_ACE 0x00000004
ACE4_INHERIT_ONLY_ACE 0x00000008
ACE4_SUCCESSFUL_ACCESS_ACE_FLAG 0x00000010
ACE4_FAILED_ACCESS_ACE_FLAG 0x00000020
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 [4] section 5.9.3: Version 4 Protocol [RFC3010] section 5.9.3:
#define ACE4_READ_DATA 0x00000001; ACE4_READ_DATA 0x00000001
#define ACE4_LIST_DIRECTORY 0x00000001; ACE4_LIST_DIRECTORY 0x00000001
#define ACE4_WRITE_DATA 0x00000002; ACE4_WRITE_DATA 0x00000002
#define ACE4_ADD_FILE 0x00000002; ACE4_ADD_FILE 0x00000002
#define ACE4_APPEND_DATA 0x00000004; ACE4_APPEND_DATA 0x00000004
#define ACE4_ADD_SUBDIRECTORY 0x00000004; ACE4_ADD_SUBDIRECTORY 0x00000004
#define ACE4_READ_NAMED_ATTRS 0x00000008; ACE4_READ_NAMED_ATTRS 0x00000008
#define ACE4_WRITE_NAMED_ATTRS 0x00000010; ACE4_WRITE_NAMED_ATTRS 0x00000010
#define ACE4_EXECUTE 0x00000020; ACE4_EXECUTE 0x00000020
#define ACE4_DELETE_CHILD 0x00000040; ACE4_DELETE_CHILD 0x00000040
#define ACE4_READ_ATTRIBUTES 0x00000080; ACE4_READ_ATTRIBUTES 0x00000080
#define ACE4_WRITE_ATTRIBUTES 0x00000100; ACE4_WRITE_ATTRIBUTES 0x00000100
#define ACE4_DELETE 0x00010000; ACE4_DELETE 0x00010000
#define ACE4_READ_ACL 0x00020000; ACE4_READ_ACL 0x00020000
#define ACE4_WRITE_ACL 0x00040000; ACE4_WRITE_ACL 0x00040000
#define ACE4_WRITE_OWNER 0x00080000; ACE4_WRITE_OWNER 0x00080000
#define ACE4_SYNCHRONIZE 0x00100000; 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 6.5) (Section 6.5)
Also, as per '5.9.4 ACE who' [4] there are several identifiers that Also, as per '5.9.4 ACE who' [RFC3010] there are several identifiers
need to be understood universally. Some of these identifiers cannot that need to be understood universally. Some of these identifiers
be understood when an client access the server, but have meaning when cannot be understood when an client access the server, but have
a local process accesses the file. The ability to display and modify meaning when a local process accesses the file. The ability to
these permissions is permitted over SFTP. display and modify 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.
INTERACTIVE Accessed from an interactive terminal. INTERACTIVE Accessed from an interactive terminal.
NETWORK Accessed via the network. NETWORK Accessed via the network.
DIALUP Accessed as a dialup user to the server. DIALUP Accessed as a dialup user to the server.
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).
skipping to change at page 22, line 7 skipping to change at page 20, line 5
To avoid conflict, these special identifiers are distinguish by an To avoid conflict, these special identifiers are distinguish by an
appended "@". For example: ANONYMOUS@. appended "@". For example: ANONYMOUS@.
6.9 attrib-bits 6.9 attrib-bits
These bits reflect various attributes of the file or directory on the These bits reflect various attributes of the file or directory on the
server. server.
The following attrib-bits are defined: The following attrib-bits are defined:
#define SSH_FILEXFER_ATTR_FLAGS_READONLY 0x00000001 SSH_FILEXFER_ATTR_FLAGS_READONLY 0x00000001
#define SSH_FILEXFER_ATTR_FLAGS_SYSTEM 0x00000002 SSH_FILEXFER_ATTR_FLAGS_SYSTEM 0x00000002
#define SSH_FILEXFER_ATTR_FLAGS_HIDDEN 0x00000004 SSH_FILEXFER_ATTR_FLAGS_HIDDEN 0x00000004
#define SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE 0x00000008 SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE 0x00000008
#define SSH_FILEXFER_ATTR_FLAGS_ARCHIVE 0x00000010 SSH_FILEXFER_ATTR_FLAGS_ARCHIVE 0x00000010
#define SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED 0x00000020 SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED 0x00000020
#define SSH_FILEXFER_ATTR_FLAGS_COMPRESSED 0x00000040 SSH_FILEXFER_ATTR_FLAGS_COMPRESSED 0x00000040
#define SSH_FILEXFER_ATTR_FLAGS_SPARSE 0x00000080 SSH_FILEXFER_ATTR_FLAGS_SPARSE 0x00000080
#define SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY 0x00000100 SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY 0x00000100
#define SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE 0x00000200 SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE 0x00000200
#define SSH_FILEXFER_ATTR_FLAGS_SYNC 0x00000400 SSH_FILEXFER_ATTR_FLAGS_SYNC 0x00000400
#define SSH_FILEXFER_ATTR_FLAGS_TRANSLATION_ERR 0x00000800 SSH_FILEXFER_ATTR_FLAGS_TRANSLATION_ERR 0x00000800
SSH_FILEXFER_ATTR_FLAGS_READONLY SSH_FILEXFER_ATTR_FLAGS_READONLY
Advisory, read-only bit. This bit is not part of the access Advisory, read-only bit. This bit is not part of the access
control information on the file, but is rather an advisory field control information on the file, but is rather an advisory field
indicating that the file should not be written. indicating that the file should not be written.
SSH_FILEXFER_ATTR_FLAGS_SYSTEM SSH_FILEXFER_ATTR_FLAGS_SYSTEM
The file is part of operating system. The file is part of operating system.
SSH_FILEXFER_ATTR_FLAGS_HIDDEN SSH_FILEXFER_ATTR_FLAGS_HIDDEN
skipping to change at page 24, line 10 skipping to change at page 22, line 10
The server MAY include this bit in a directory listing or realpath The server MAY include this bit in a directory listing or realpath
response. It indicates there was a failure in the translation to response. It indicates there was a failure in the translation to
UTF-8. If this flag is included, the server SHOULD also include UTF-8. If this flag is included, the server SHOULD also include
the UNTRANSLATED_NAME attribute. the UNTRANSLATED_NAME attribute.
6.10 Text Hint 6.10 Text Hint
The value is one of the following enumerations, and indicates what The value is one of the following enumerations, and indicates what
the server knows about the content of the file. the server knows about the content of the file.
#define SSH_FILEXFER_ATTR_KNOWN_TEXT 0x01 SSH_FILEXFER_ATTR_KNOWN_TEXT 0x00
#define SSH_FILEXFER_ATTR_GUESSED_TEXT 0x01 SSH_FILEXFER_ATTR_GUESSED_TEXT 0x01
#define SSH_FILEXFER_ATTR_KNOWN_BINARY 0x01 SSH_FILEXFER_ATTR_KNOWN_BINARY 0x02
#define SSH_FILEXFER_ATTR_GUESSED_BINARY 0x01 SSH_FILEXFER_ATTR_GUESSED_BINARY 0x03
SSH_FILEXFER_ATTR_KNOWN_TEXT SSH_FILEXFER_ATTR_KNOWN_TEXT
The server knows the file is a text file, and should be opened The server knows the file is a text file, and should be opened
using the SSH_FXF_ACCESS_TEXT_MODE flag. using the SSH_FXF_ACCESS_TEXT_MODE flag.
SSH_FILEXFER_ATTR_GUESSED_TEXT SSH_FILEXFER_ATTR_GUESSED_TEXT
The server has applied a hueristic or other mechanism and believes The server has applied a hueristic or other mechanism and believes
that the file should be opened with the SSH_FXF_ACCESS_TEXT_MODE that the file should be opened with the SSH_FXF_ACCESS_TEXT_MODE
flag. flag.
skipping to change at page 24, line 39 skipping to change at page 22, line 39
has binary content, and should not be opened with the has binary content, and should not be opened with the
SSH_FXF_ACCESS_TEXT_MODE flag. SSH_FXF_ACCESS_TEXT_MODE flag.
This flag MUST NOT be present during a setstat operation. If this This flag MUST NOT be present during a setstat operation. If this
flag is present during an fsetstat operation, the file handle is flag is present during an fsetstat operation, the file handle is
converted to a text-mode handle, as if it had been opened with converted to a text-mode handle, as if it had been opened with
SSH_FXF_ACCESS_TEXT_MODE. SSH_FXF_ACCESS_TEXT_MODE.
6.11 Mime type 6.11 Mime type
The 'mime-type' field contains the mime-type [9] string. Most The 'mime-type' field contains the mime-type [RFC1521] string. Most
servers will not know this information and should not set the bit in servers will not know this information and should not set the bit in
their supported-attribute-mask. their supported-attribute-mask.
6.12 Link Count 6.12 Link Count
The 'link-count' field contains the hard link count of the file. The 'link-count' field contains the hard link count of the file.
This attribute MUST NOT be present during a setstat operation. This attribute MUST NOT be present during a setstat operation.
6.13 Extended Attributes 6.13 Extended Attributes
skipping to change at page 26, line 31 skipping to change at page 23, line 51
implementation, as well as an implementation which caches state implementation, as well as an implementation which caches state
between requests but may also flush it. The contents of the file between requests but may also flush it. The contents of the file
handle string are entirely up to the server and its design. The handle string are entirely up to the server and its design. The
client should not modify or attempt to interpret the file handle client should not modify or attempt to interpret the file handle
strings. strings.
The file handle strings MUST NOT be longer than 256 bytes. The file handle strings MUST NOT be longer than 256 bytes.
7.1.1 Opening a File 7.1.1 Opening a File
Files are opened and created using the SSH_FXP_OPEN message: Files are opened and created using the SSH_FXP_OPEN message.
byte SSH_FXP_OPEN byte SSH_FXP_OPEN
uint32 request-id uint32 request-id
string filename [UTF-8] string filename [UTF-8]
uint32 desired-access uint32 desired-access
uint32 flags uint32 flags
ATTRS attrs ATTRS attrs
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.)
The 'request-id' field is the request identifier as for all requests. 7.1.1.1 filename
The 'filename' field specifies the file name. See Section ''File The 'filename' field specifies the file name. See Section ''File
Names'' for more information. Names'' for more information. If 'filename' is a directory file, the
server MUST return an SSH_FX_FILE_IS_A_DIRECTORY error.
7.1.1.2 desired-access
The 'desired-access' field is a bitmask containing a combination of The 'desired-access' field is a bitmask containing a combination of
values from the ace-mask flags from section 5.7. values from the ace-mask flags from section 5.7.
The server MUST be prepared to translate the SFTP access flags into
it's local equivilants. If the server can not grant the access
desired, it MUST return SSH_FX_PERMISSION_DENIED.
The server MAY open the file with greater access than requested if
the user has such access and the server implementation requires it.
For example, a server that does not distinguish between
READ_ATTRIBUTE and READ_DATA will have to request full 'read' access
to the file when the client only requested READ_ATTRIBUTE, resulting
in greater access than the client originaly requested.
In such cases, it is possible, and permissable in the protocol, that
the client could open a file requesting some limitted access, and
then access the file in a way not permitted by that limitted access
and the server would permit such action. However, the server MUST
NOT ever grant access to the file that the client does not actually
have the rights to.
7.1.1.3 flags
The 'flags' field controls various aspects of the operation, The 'flags' field controls various aspects of the operation,
including whether or not the file is created and the kind of locking including whether or not the file is created and the kind of locking
desired. desired.
The following 'flags' are defined: The following 'flags' are defined:
SSH_FXF_ACCESS_DISPOSITION = 0x00000007 SSH_FXF_ACCESS_DISPOSITION = 0x00000007
SSH_FXF_CREATE_NEW = 0x00000000 SSH_FXF_CREATE_NEW = 0x00000000
SSH_FXF_CREATE_TRUNCATE = 0x00000001 SSH_FXF_CREATE_TRUNCATE = 0x00000001
SSH_FXF_OPEN_EXISTING = 0x00000002 SSH_FXF_OPEN_EXISTING = 0x00000002
SSH_FXF_OPEN_OR_CREATE = 0x00000003 SSH_FXF_OPEN_OR_CREATE = 0x00000003
SSH_FXF_TRUNCATE_EXISTING = 0x00000004 SSH_FXF_TRUNCATE_EXISTING = 0x00000004
SSH_FXF_ACCESS_APPEND_DATA = 0x00000008 SSH_FXF_ACCESS_APPEND_DATA = 0x00000008
SSH_FXF_ACCESS_APPEND_DATA_ATOMIC = 0x00000010 SSH_FXF_ACCESS_APPEND_DATA_ATOMIC = 0x00000010
SSH_FXF_ACCESS_TEXT_MODE = 0x00000020 SSH_FXF_ACCESS_TEXT_MODE = 0x00000020
SSH_FXF_ACCESS_READ_LOCK = 0x00000040 SSH_FXF_ACCESS_READ_LOCK = 0x00000040
SSH_FXF_ACCESS_WRITE_LOCK = 0x00000080 SSH_FXF_ACCESS_WRITE_LOCK = 0x00000080
SSH_FXF_ACCESS_DELETE_LOCK = 0x00000100 SSH_FXF_ACCESS_DELETE_LOCK = 0x00000100
SSH_FXF_NOFOLLOW = 0x00000200 SSH_FXF_ACCESS_NOFOLLOW = 0x00000200
SSH_FXF_ACCESS_DELETE_ON_CLOSE = 0x00000400
SSH_FXF_ACCESS_DISPOSITION SSH_FXF_ACCESS_DISPOSITION
Disposition is a 3 bit field that controls how the file is opened. Disposition is a 3 bit field that controls how the file is opened.
The server MUST support these bits. Any one of the following The server MUST support these bits. Any one of the following
enumeration is allowed: enumeration is allowed:
SSH_FXF_CREATE_NEW SSH_FXF_CREATE_NEW
A new file is created; if the file already exists, the server A new file is created; if the file already exists, the server
MUST return status SSH_FX_FILE_ALREADY_EXISTS. MUST return status SSH_FX_FILE_ALREADY_EXISTS.
SSH_FXF_CREATE_TRUNCATE SSH_FXF_CREATE_TRUNCATE
A new file is created; if the file already exists, it is A new file is created; if the file already exists, it is opened
truncated. and truncated.
SSH_FXF_OPEN_EXISTING SSH_FXF_OPEN_EXISTING
An existing file is opened. If the file does not exist, the An existing file is opened. If the file does not exist, the
server MUST return SSH_FX_NO_SUCH_FILE. If a directory in the server MUST return SSH_FX_NO_SUCH_FILE. If a directory in the
path does not exist, the server SHOULD return path does not exist, the server SHOULD return
SSH_FX_NO_SUCH_PATH. It is also acceptable if the server SSH_FX_NO_SUCH_PATH. It is also acceptable if the server
returns SSH_FX_NO_SUCH_FILE in this case. returns SSH_FX_NO_SUCH_FILE in this case.
SSH_FXF_OPEN_OR_CREATE SSH_FXF_OPEN_OR_CREATE
If the file exists, it is opened. If the file does not exist, If the file exists, it is opened. If the file does not exist,
skipping to change at page 29, line 37 skipping to change at page 27, line 34
SSH_FXF_ACCESS_WRITE_LOCK SSH_FXF_ACCESS_WRITE_LOCK
The file should be opened with a write lock. The server MUST The file should be opened with a write lock. The server MUST
gaurantee that the client will be the exclusive writer of the file gaurantee that the client will be the exclusive writer of the file
until the client closes the handle. until the client closes the handle.
SSH_FXF_ACCESS_DELETE_LOCK SSH_FXF_ACCESS_DELETE_LOCK
The file should be opened with a delete lock. The server MUST The file should be opened with a delete lock. The server MUST
gaurantee that the file will not be deleted until the client gaurantee that the file will not be deleted until the client
closes the handle. closes the handle.
SSH_FXF_NOFOLLOW SSH_FXF_ACCESS_NOFOLLOW
If the final component of the path is a symlink, then the open If the final component of the path is a symlink, then the open
MUST fail, and the error SSH_FX_LINK_LOOP MUST be returned. MUST fail, and the error SSH_FX_LINK_LOOP MUST be returned.
SSH_FXF_ACCESS_DELETE_ON_CLOSE
The file should be deleted when the last handle to it is closed.
(The last handle may not be an sftp-handle.) This MAY be emulated
by a server if the OS doesn't support it by deleting the file when
this handle is closed.
The 'attrs' field specifies the initial attributes for the file. The 'attrs' field specifies the initial attributes for the file.
Default values MUST be supplied by the server for those attributes Default values MUST be supplied by the server for those attributes
that are not specified. See Section ''File Attributes'' for more that are not specified. See Section ''File Attributes'' for more
information. information.
The 'attrs' field is ignored if an exiting file is opened. The 'attrs' field is ignored if an exiting file is opened.
The following table is provided to assist in mapping posix semantics The following table is provided to assist in mapping posix semantics
to equivalent SFTP file open parameters: to equivalent SFTP file open parameters:
O_RDONLY O_RDONLY
desired-access = READ_DATA|READ_ATTRIBUTES desired-access = READ_DATA|READ_ATTRIBUTES
O_WRONLY O_WRONLY
desired-access = WRITE_DATA|WRITE_ATTRIBUTES desired-access = WRITE_DATA|WRITE_ATTRIBUTES
O_RDWR O_RDWR
desired-access = desired-access =
READ_DATA|READ_ATTRIBUTES|WRITE_DATA|WRITE_ATTRIBUTES READ_DATA|READ_ATTRIBUTES|WRITE_DATA|WRITE_ATTRIBUTES
skipping to change at page 30, line 39 skipping to change at page 28, line 39
7.1.2 Opening a Directory 7.1.2 Opening a Directory
To enumerate a directory, the client first obtains a handle and then To enumerate a directory, the client first obtains a handle and then
issues directory read requests. When enumeration is complete, the issues directory read requests. When enumeration is complete, the
handle MUST be closed. handle MUST be closed.
byte SSH_FXP_OPENDIR byte SSH_FXP_OPENDIR
uint32 request-id uint32 request-id
string path [UTF-8] string path [UTF-8]
'request-id' is the request identifier. path
The 'path' field is the path name of the directory to be listed
(without any trailing slash). See Section 'File Names' for more
information on file names.
'path' is the path name of the directory to be listed (without any If 'path' does not refer to a directory, the server MUST return
trailing slash). See Section 'File Names' for more information on SSH_FX_NOT_A_DIRECTORY.
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).
7.1.3 Closing Handles 7.1.3 Closing Handles
A handle is closed using the following request. A handle is closed using the following request.
byte SSH_FXP_CLOSE byte SSH_FXP_CLOSE
uint32 request-id uint32 request-id
string handle string handle
'request-id' is the request identifier, and 'handle' is a handle handle
previously returned in the response to SSH_FXP_OPEN or 'handle' is a handle previously returned in the response to
SSH_FXP_OPENDIR. The handle becomes invalid immediately after this SSH_FXP_OPEN or SSH_FXP_OPENDIR. The handle becomes invalid
request has been sent. immediately after this request has been sent.
The response to this request will be a SSH_FXP_STATUS message. Note The response to this request will be a SSH_FXP_STATUS message. Note
that on some server platforms even a close can fail. For example, if that on some server platforms even a close can fail. For example, if
the server operating system caches writes, and an error occurs while the server operating system caches writes, and an error occurs while
flushing cached writes, the close operation may fail. flushing cached writes, the close operation may fail.
7.2 Reading and Writing 7.2 Reading and Writing
7.2.1 Reading Files 7.2.1 Reading Files
The following request can be used to read file data: The following request can be used to read file data:
byte SSH_FXP_READ byte SSH_FXP_READ
uint32 request-id uint32 request-id
string handle string handle
uint64 offset uint64 offset
uint32 length uint32 length
where 'request-id' is the request identifier, 'handle' is an open handle
file handle returned by SSH_FXP_OPEN, 'offset' is the offset (in 'handle' is an open file handle returned by SSH_FXP_OPEN. If
bytes) relative to the beginning of the file from where to start 'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST
reading, and 'length' is the maximum number of bytes to read. return SSH_FX_INVALID_HANDLE.
In response to this request, the server will read as many bytes as it offset
can from the file (up to 'length'), and return them in a SSH_FXP_DATA 'offset' is the offset (in bytes) relative to the beginning of the
message. If an error occurs or EOF is encountered before reading any file that the read MUST start at. 'offset' is ignored if
data, the server will respond with SSH_FXP_STATUS. SSH_FXF_TEXT was specified during the open.
For normal disk files, it is normally guaranteed that this will read length
the specified number of bytes, or up to end of file. However, if the 'length' is the maximum number of bytes to read.
read length is very long, the server may truncate it if it doesn't
support packets of that length. See General Packet Format (Section The server MUST not respond with more data than is specified by
3). the 'length' parameter. However, the server MAY respond with less
data if EOF is reached, an error is encountered, or the servers
internal buffers can not handle such a large request.
For normal disk files, it is normally guaranteed that this will
read the specified number of bytes, or up to end of file.
If the server specified 'max-read-size' then failure to return
'length' bytes indicates that EOF or an error occured.
7.2.2 Reading Directories 7.2.2 Reading Directories
In order to retrieve a directory listing, the client issues one or In order to retrieve a directory listing, the client issues one or
more SSH_FXP_READDIR requests. In order to obtain a complete more SSH_FXP_READDIR requests. In order to obtain a complete
directory listing, the client MUST issue repeated SSH_FXP_READDIR directory listing, the client MUST issue repeated SSH_FXP_READDIR
requests until the server responds with an SSH_FXP_STATUS message. requests until the server responds with an SSH_FXP_STATUS message.
byte SSH_FXP_READDIR byte SSH_FXP_READDIR
uint32 request-id uint32 request-id
string handle string handle
where 'request-id' is the request identifier, and 'handle' is a handle
handle returned by SSH_FXP_OPENDIR. (It is a protocol error to 'handle' is a handle returned by SSH_FXP_OPENDIR. If 'handle' is
attempt to use an ordinary file handle returned by SSH_FXP_OPEN.) an oridinary file handle returned by SSH_FXP_OPEN, the server MUST
return SSH_FX_INVALID_HANDLE.
The server responds to this request with either a SSH_FXP_NAME or a 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. 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 Full status information is returned for each name in order to speed
up typical directory listings. up typical directory listings.
If there are no more names available to be read, the server MUST 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. respond with a SSH_FXP_STATUS message with error code of SSH_FX_EOF.
7.2.3 Writing Files 7.2.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 request-id uint32 request-id
string handle string handle
uint64 offset uint64 offset
string data string data
where 'request-id' is a request identifier, 'handle' is a file handle handle
returned by SSH_FXP_OPEN, 'offset' is the offset (in bytes) from the 'handle' is an open file handle returned by SSH_FXP_OPEN. If
beginning of the file where to start writing, and 'data' is the data 'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST
to be written. return SSH_FX_INVALID_HANDLE.
The write will extend the file if writing beyond the end of the file. offset
It is legal to write to an offset that extends beyond the end of the 'offset' is the offset (in bytes) relative to the beginning of the
file; the semantics are to write zeroes from the end of the file to file that the write MUST start at. 'offset' is ignored if
the specified offset and then the data. On most operating systems, SSH_FXF_TEXT was specified during the open.
such writes do not allocate disk space but instead create a sparse
file. The write will extend the file if writing beyond the end of the
file. It is legal to write to an offset that extends beyond the
end of the file; the semantics are to write zeroes from the end of
the file to the specified offset and then the data. On most
operating systems, such writes do not allocate disk space but
instead create a sparse file.
data
The data to write to the 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.
7.3 Removing and Renaming Files 7.3 Removing and Renaming Files
The following request can be used to remove a file: The following request can be used to remove a file:
byte SSH_FXP_REMOVE byte SSH_FXP_REMOVE
uint32 request-id uint32 request-id
string filename [UTF-8] string filename [UTF-8]
where 'request-id' is the request identifier and 'filename' is the
name of the file to be removed. See Section ''File Names'' for more filename
information. This request cannot be used to remove directories. 'filename' is the name of the file to be removed. See Section
'File Names' for more information.
This request cannot be used to remove directories. The server
MUST return SSH_FX_FILE_IS_A_DIRECTORY in this case.
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. message.
byte SSH_FXP_RENAME byte SSH_FXP_RENAME
uint32 request-id uint32 request-id
string oldpath [UTF-8] string oldpath [UTF-8]
skipping to change at page 35, line 37 skipping to change at page 34, line 16
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). information for an open file (identified by the file handle).
byte SSH_FXP_FSTAT byte SSH_FXP_FSTAT
uint32 request-id uint32 request-id
string handle string handle
uint32 flags uint32 flags
where 'request-id' is the request identifier and 'handle' is a file handle
handle returned by SSH_FXP_OPEN. The server responds to this request 'handle' is an open file handle returned by SSH_FXP_OPEN. If
with SSH_FXP_ATTRS or SSH_FXP_STATUS. 'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST
return SSH_FX_INVALID_HANDLE.
The server responds to this request with SSH_FXP_ATTRS or
SSH_FXP_STATUS.
7.6 Setting File Attributes 7.6 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. SSH_FXP_FSETSTAT requests.
byte SSH_FXP_SETSTAT byte SSH_FXP_SETSTAT
uint32 request-id uint32 request-id
string path [UTF-8] string path [UTF-8]
ATTRS attrs ATTRS attrs
skipping to change at page 36, line 4 skipping to change at page 34, line 33
7.6 Setting File Attributes 7.6 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. SSH_FXP_FSETSTAT requests.
byte SSH_FXP_SETSTAT byte SSH_FXP_SETSTAT
uint32 request-id uint32 request-id
string path [UTF-8] string path [UTF-8]
ATTRS attrs ATTRS attrs
byte SSH_FXP_FSETSTAT byte SSH_FXP_FSETSTAT
uint32 request-id uint32 request-id
string handle string handle
ATTRS attrs ATTRS attrs
request-id
The request identifier to be returned as part of the response.
path path
The file system object (e.g. file or directory) whose attributes The file system object (e.g. file or directory) whose attributes
are to be modified. If this object does not exist, or the user are to be modified. If this object does not exist, or the user
does not have sufficient access to write the attributes, the does not have sufficient access to write the attributes, the
request MUST fail. request MUST fail.
handle handle
The handle is a handle previously returned from a SSH_FXP_OPEN 'handle' is an open file handle returned by SSH_FXP_OPEN. If
request which identifies the file whose attributes are to be 'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST
modified. If the handle was not opened with sufficient access to return SSH_FX_INVALID_HANDLE. If the handle was not opened with
write the requested attributes, the request MUST fail. sufficient access to write the requested attributes, the request
MUST fail.
attrs attrs
Specifies the modified attributes to be applied. Attributes are Specifies the modified attributes to be applied. Attributes are
discussed in more detail in Section ''File Attributes''. discussed in more detail in Section ''File Attributes''.
The server will respond with a SSH_FXP_STATUS message. The server will respond with a SSH_FXP_STATUS message.
Because some systems must use separate system calls to set various Because some systems must use separate system calls to set various
attributes, it is possible that a failure response will be returned, attributes, it is possible that a failure response will be returned,
but yet some of the attributes may be have been successfully but yet some of the attributes may be have been successfully
modified. If possible, servers SHOULD avoid this situation; however, modified. If possible, servers SHOULD avoid this situation; however,
client MUST be aware that this is possible. client MUST be aware that this is possible.
7.7 Dealing with Symbolic Links 7.7 Dealing with Links
The SSH_FXP_READLINK request reads the target of a symbolic link. The SSH_FXP_READLINK request reads the target of a symbolic link.
byte SSH_FXP_READLINK byte SSH_FXP_READLINK
uint32 request-id uint32 request-id
string path [UTF-8] string path [UTF-8]
where 'request-id' is the request identifier and 'path' specifies the where 'request-id' is the request identifier and 'path' specifies the
path name of the symlink to be read. 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 creates a symbolic link on the server. The SSH_FXP_LINK request creates a symbolic link on the server.
byte SSH_FXP_SYMLINK byte SSH_FXP_LINK
uint32 request-id uint32 request-id
string linkpath [UTF-8] string new-link-path [UTF-8]
string targetpath [UTF-8] string existing-path [UTF-8]
bool sym-link
where 'request-id' is the request identifier, 'linkpath' specifies new-link-path
the path name of the symlink to be created and 'targetpath' specifies Specifies the path name of the new link to create.
the target of the symlink. The server shall respond with a
SSH_FXP_STATUS. existing-path
Specifies the path of an existing file system object to which the
new-link-path will refer.
sym-link
Specifies that the link should be a symbolic link, or a special
file that redirects file system parsing to the resulting path. It
is generally possible to create symbolic links across device
boundaries; however, it is not required that a server support
this.
If 'sym-link' is false, the link should be a hard link, or a
second directory entry refering to the same file or directory
object. It is generally not possible to create hard links across
devices.
The server shall respond with a SSH_FXP_STATUS. Clients should be
aware that some server may return SSH_FX_OP_UNSUPPORTED for either
the hard-link, sym-link, or both operations.
7.8 Canonicalizing the Server-Side Path Name 7.8 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:
byte SSH_FXP_REALPATH byte SSH_FXP_REALPATH
uint32 request-id uint32 request-id
string path [UTF-8] string original-path [UTF-8]
string compose-path [optional]
byte control-byte [optional]
where 'request-id' is the request identifier and 'path' specifies the original-path
path name to be canonicalized. The server will respond with a The first component of the path which the client wishes resolved
SSH_FXP_NAME packet containing the name in canonical form and a dummy into a absolute canonical path. This may be the entire path.
attributes value. If an error occurs, the server may also respond
with SSH_FXP_STATUS.
The server SHOULD fail the request if the path is not present on the compose-path
server. A path which the client wishs the server to compose with the
original path to form the new path. This field is optional, and
if it is not present in the packet, it is assumed to be a zero
length string.
control-byte
SSH_FXP_REALPATH_NO_CHECK 0x00000001
SSH_FXP_REALPATH_STAT_IF 0x00000002
SSH_FXP_REALPATH_STAT_ALWAYS 0x00000003
This field is optional, and if it is not present in the packet, it
is assumed to be SSH_FXP_REALPATH_NO_CHECK.
If SSH_FXP_REALPATH_NO_CHECK is specified, the server MUST NOT
fail the request if the path does not exist, is hidden, or the
user does not have access to the path or some component thereof.
However, the path MAY NOT be completely resolved to it's component
form. For example, symlinks may not be followed in this case.
The server MAY fail the request if the path is not syntaticly
valid, or for other reasons.
If SSH_FXP_REALPATH_STAT_IF is specified, the server MUST stat the
path if it exists and is accessible to the client. However, if
the path does not exist, isn't visible, or isn't accessible, the
server MUST NOT fail the request. If the stat failed, the file
type will be SSH_FILEXFER_TYPE_UNKNOWN. If the client needs to
distinguish between files that are actually
SSH_FILEXFER_TYPE_UNKNOWN and paths that don't exist, it will
have to issue a seperate stat command in this case.
If SSH_FXP_REALPATH_STAT_ALWAYS is specified the server MUST stat
the path. If the stat operation fails, the server MUST fail the
request.
The server MUST take the 'original-path' and apply the 'compose-path'
as a modification to it. 'compose-path' MAY be relative to
'original-path' or may be an absolute path, in which case
'original-path' will be discarded. The 'compose-path' may be zero
length.
The server will respond with a SSH_FXP_NAME packet containing the
canonical form of the composite path. If SSH_FXP_REALPATH_NO_CHECK
is specified, the attributes are dummy values.
7.8.1 Best Practice for Dealing with Paths 7.8.1 Best Practice for Dealing with Paths
BEGIN: RFCEDITOR REMOVE BEFORE PUBLISHING
Previous to this version, clients typically composed new paths
themselves and then called both realpath and stat on the resulting
path to get it's canonical name and see if it really existed and was
a directory.
This required clients to assume certain things about how a relative
vs. realpath looked. The new realpath allows clients to no longer
make those assumptions and to remove one round trip from the process
and get deterministic behavior from all servers.
END: RFCEDITOR REMOVE BEFORE PUBLISHING
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
absolute, even if there is no leading slash, will continue to as 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.
The client SHOULD also use SSH_FXP_REALPATH call to compose paths so
that it does not need to know when a path is absolute or relative.
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
"c:/x/y/z/..". REALPATH("c:/x/y/z", "..", SSH_FXP_REALPATH_STAT_ALWAYS)
As a second example, if the client wishes to open the file "x.txt" in As a second example, if the client wishes transfer local file "a" to
the current directory, and server has returned "dka100:/x/y/z" as the remote file "/b/d/e", and server has returned "dka100:/x/y/z" as the
canonical path of the directory, the client SHOULD open canonical path of the current directory, the client SHOULD send
"dka100:/x/y/z/x.txt" REALPATH("dka100:/x/y/z", "/b/d/e", SSH_FXP_REALPATH_STAT_IF). This
call will determine the correct path to use for the open request and
whether the /b/d/e represents a directory.
8. Responses from the Server to the Client 8. 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, and no data needs to be failure. When the operation is successful, and no data needs to be
returned, the SSH_FXP_STATUS response with SSH_FX_OK status is returned, the SSH_FXP_STATUS response with SSH_FX_OK status is
appropriate. appropriate.
Exactly one response will be returned for each request. Each Exactly one response will be returned for each request. Each
skipping to change at page 40, line 7 skipping to change at page 39, line 24
Human readable description of the error. 'language tag' specifies Human readable description of the error. 'language tag' specifies
the language the error is in. the language the error is in.
<error-specific data> <error-specific data>
The error-specific data may be empty, or may contain additional The error-specific data may be empty, or may contain additional
information about the error. For error codes that send information about the error. For error codes that send
error-specific data, the format of the data is defined below. error-specific data, the format of the data is defined below.
Error codes: Error codes:
#define SSH_FX_OK 0 SSH_FX_OK 0
#define SSH_FX_EOF 1 SSH_FX_EOF 1
#define SSH_FX_NO_SUCH_FILE 2 SSH_FX_NO_SUCH_FILE 2
#define SSH_FX_PERMISSION_DENIED 3 SSH_FX_PERMISSION_DENIED 3
#define SSH_FX_FAILURE 4 SSH_FX_FAILURE 4
#define SSH_FX_BAD_MESSAGE 5 SSH_FX_BAD_MESSAGE 5
#define SSH_FX_NO_CONNECTION 6 SSH_FX_NO_CONNECTION 6
#define SSH_FX_CONNECTION_LOST 7 SSH_FX_CONNECTION_LOST 7
#define SSH_FX_OP_UNSUPPORTED 8 SSH_FX_OP_UNSUPPORTED 8
#define SSH_FX_INVALID_HANDLE 9 SSH_FX_INVALID_HANDLE 9
#define SSH_FX_NO_SUCH_PATH 10 SSH_FX_NO_SUCH_PATH 10
#define SSH_FX_FILE_ALREADY_EXISTS 11 SSH_FX_FILE_ALREADY_EXISTS 11
#define SSH_FX_WRITE_PROTECT 12 SSH_FX_WRITE_PROTECT 12
#define SSH_FX_NO_MEDIA 13 SSH_FX_NO_MEDIA 13
#define SSH_FX_NO_SPACE_ON_FILESYSTEM 14 SSH_FX_NO_SPACE_ON_FILESYSTEM 14
#define SSH_FX_QUOTA_EXCEEDED 15 SSH_FX_QUOTA_EXCEEDED 15
#define SSH_FX_UNKNOWN_PRINCIPLE 16 SSH_FX_UNKNOWN_PRINCIPLE 16
#define SSH_FX_LOCK_CONFlICT 17 SSH_FX_LOCK_CONFLICT 17
#define SSH_FX_DIR_NOT_EMPTY 18 SSH_FX_DIR_NOT_EMPTY 18
#define SSH_FX_NOT_A_DIRECTORY 19 SSH_FX_NOT_A_DIRECTORY 19
#define SSH_FX_INVALID_FILENAME 20 SSH_FX_INVALID_FILENAME 20
#define SSH_FX_LINK_LOOP 21 SSH_FX_LINK_LOOP 21
SSH_FX_CANNOT_DELETE 22
SSH_FX_INVALID_PARAMETER 23
SSH_FX_FILE_IS_A_DIRECTORY 24
SSH_FX_BYTE_RANGE_LOCK_CONFLICT 25
SSH_FX_BYTE_RANGE_LOCK_REFUSED 26
SSH_FX_DELETE_PENDING 27
SSH_FX_FILE_CORRUPT 28
SSH_FX_OK SSH_FX_OK
Indicates successful completion of the operation. Indicates successful completion of the operation.
SSH_FX_EOF SSH_FX_EOF
An attempt to read past the end-of-file was made; or, there are no An attempt to read past the end-of-file was made; or, there are no
more directory entries to return. more directory entries to return.
SSH_FX_NO_SUCH_FILE SSH_FX_NO_SUCH_FILE
A reference was made to a file which does not exist. A reference was made to a file which does not exist.
skipping to change at page 42, line 31 skipping to change at page 42, line 5
SSH_FX_NOT_A_DIRECTORY SSH_FX_NOT_A_DIRECTORY
The specified file is not a directory. The specified file is not a directory.
SSH_FX_INVALID_FILENAME SSH_FX_INVALID_FILENAME
The filename is not valid. The filename is not valid.
SSH_FX_LINK_LOOP SSH_FX_LINK_LOOP
Too many symbolic links encountered. Too many symbolic links encountered.
SSH_FX_CANNOT_DELETE
The file cannot be deleted. One possible reason is that the
advisory READONLY attribute-bit is set.
SSH_FX_INVALID_PARAMETER
On of the parameters was out of range, or the parameters specified
cannot be used together.
SSH_FX_FILE_IS_A_DIRECTORY
The specifed file was a directory in a context where a directory
cannot be used.
SSH_FX_BYTE_RANGE_LOCK_CONFLICT
A read or write operation failed because another process owns a
byte range lock that conflicts.
SSH_FX_BYTE_RANGE_LOCK_REFUSED
A request for a byte range lock was refused.
SSH_FX_DELETE_PENDING
An operation was attempted on a file for which a delete operation
is pending.
SSH_FX_FILE_CORRUPT
The file is corrupt; an filesystem integrity check should be run.
The SSH_FXP_HANDLE response has the following format: The SSH_FXP_HANDLE response has the following format:
byte SSH_FXP_HANDLE byte SSH_FXP_HANDLE
uint32 request-id uint32 request-id
string handle string handle
where 'request-id' is the request identifier, and 'handle' is an 'handle'
arbitrary string that identifies an open file or directory on the An arbitrary string that identifies an open file or directory on
server. The handle is opaque to the client; the client MUST NOT the server. The handle is opaque to the client; the client MUST
attempt to interpret or modify it in any way. The length of the NOT attempt to interpret or modify it in any way. The length of
handle string MUST NOT exceed 256 data bytes. the 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:
byte SSH_FXP_DATA byte SSH_FXP_DATA
uint32 request-id uint32 request-id
string data string data
bool end-of-file [optional]
data
'data' is an arbitrary byte string containing the requested data.
The data string may be at most the number of bytes requested in a
SSH_FXP_READ request, but may also be shorter. (See
Section 7.2.1.)
where 'request-id' is the request identifier, and 'data' is an end-of-file
arbitrary byte string containing the requested data. The data string This field is optional. If it is present in the packet, it MUST
may be at most the number of bytes requested in a SSH_FXP_READ be true, and it indicates that EOF was reached during this read.
request, but may also be shorter if end of file is reached or if the This can help the client avoid a round trip to determine whether a
read is from something other than a regular file. short read was normal (due to EOF) or some other problem (limitted
server buffer for example.)
The SSH_FXP_NAME response has the following format: The SSH_FXP_NAME response has the following format:
byte SSH_FXP_NAME byte SSH_FXP_NAME
uint32 request-id 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
bool end-of-list [optional]
where 'request-id' is the request identifier, 'count' is the number count
of names returned in this response, and the remaining fields repeat The number of names returned in this response, and the remaining
'count' times. In the repeated part, 'filename' is a file name being fields repeat 'count' times.
returned (for SSH_FXP_READDIR, it will be a relative name within the
directory, without any path components; for SSH_FXP_REALPATH it will filename
be an absolute path name), and 'attrs' is the attributes of the file A file name being returned (for SSH_FXP_READDIR, it will be a
as described in Section ''File Attributes''. relative name within the directory, without any path components;
for SSH_FXP_REALPATH it will be an absolute path name.)
attrs
The attributes of the file as described in Section ''File
Attributes''.
end-of-list
This field is optional. If present in the packet, it MUST be
true, and indicates that there are no more entries to be read.
This can save the client a round trip to determine if there are
more entries to be read.
The SSH_FXP_ATTRS response has the following format: The SSH_FXP_ATTRS response has the following format:
byte SSH_FXP_ATTRS byte SSH_FXP_ATTRS
uint32 request-id uint32 request-id
ATTRS attrs ATTRS attrs
where 'request-id' is the request identifier, and 'attrs' is the where 'request-id' is the request identifier, and 'attrs' is the
returned file attributes as described in Section ''File Attributes''. returned file attributes as described in Section ''File Attributes''.
skipping to change at page 45, line 11 skipping to change at page 45, line 18
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.
9.1 Checking File Contents 9.1 File Hashing
BEGIN: RFCEDITOR REMOVE BEFORE PUBLISHING
After some discussion of this at connectathon, I know of two uses for
this feature, neither one of which the feature is entirely suited
for:
o Checking that a file has been uploaded to the server correctly;
some portion of the customers wanting this feature want it in a
security sense, as part of proof the server has the file.
o Optimizing upload or download of the file; multiple hashes are
performed on small pieces of the file and the results are used to
determine what chunks of the file, if any, need to be transfered.
This is similar to the way rsync works.
I've seen both of these implemented.
For the first case, the extension has several drawbacks, including:
o A FIPS implementation can't ship md5.
o MD5's security is potential weaker than other options.
o Being hard-coded to MD5 makes in impossible to adapt to future
developments in the arena of MD5 compromises.
For the second case, the extension has these drawbacks:
o MD5 is expensive (relative to other options.)
o The extension must be sent potentially thousands of times to
retrieve the desired granularity of hashes.
Therefore, for this draft, this section is marked experimental; I've
included a second proposed extension. Please post your thoughts on
the mailing list. (I did it this way just so I could get a draft out
that I and my active co-author are happy with.
In addition, implemenation experience has shown the quick check hash
to not be useful.
END: RFCEDITOR REMOVE BEFORE PUBLISHING
9.1.1 Checking File Contents: v5 extension
This extension allows a client to easily check if a file (or portion This extension allows a client to easily check if a file (or portion
thereof) that it already has matches what is on the server. thereof) that it already has matches what is on the server.
byte SSH_FXP_EXTENDED byte SSH_FXP_EXTENDED
uint32 request-id uint32 request-id
string "md5-hash" / "md5-hash-handle" string "md5-hash" / "md5-hash-handle"
string filename / file-handle string filename [UTF-8] / file-handle
uint64 start-offset uint64 start-offset
uint64 length uint64 length
string quick-check-hash string quick-check-hash
filename filename
Used if "md5-hash" is specified; indicates the name of the file to Used if "md5-hash" is specified; indicates the name of the file to
use. The has will be of the file contents as it would appear on use. The hash will be of the file contents as it would appear on
the wire if the file were opened with no special flags. the wire if the file were opened with no special flags.
file-handle file-handle
Used if "md5-hash-handle" is specified; specifies a file handle to Used if "md5-hash-handle" is specified; specifies a file handle to
read the data from. The handle MUST be a file handle, and read the data from. The handle MUST be a file handle, and
ACE4_READ_DATA MUST have been included in the desired-access when ACE4_READ_DATA MUST have been included in the desired-access when
the file was opened. the file was opened.
If this file handle was opened in TEXT mode, the md5-hash must be If this file handle was opened in TEXT mode, the md5-hash must be
made of the data as it would be sent on the wire. made of the data as it would be sent on the wire.
skipping to change at page 46, line 23 skipping to change at page 47, line 18
byte SSH_FXP_EXTENDED_REPLY byte SSH_FXP_EXTENDED_REPLY
uint32 request-id uint32 request-id
string "md5-hash" string "md5-hash"
string hash string hash
If 'hash' is zero length, then the 'quick-check-hash' did not match, If 'hash' is zero length, then the 'quick-check-hash' did not match,
and no hash operation was preformed. Otherwise, 'hash' contains the and no hash operation was preformed. Otherwise, 'hash' contains the
hash of the entire data range (including the first 2048 bytes that hash of the entire data range (including the first 2048 bytes that
were included in the 'quick-check-hash'.) were included in the 'quick-check-hash'.)
9.1.2 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 "check-file"
string handle
string hash-algorithm-list
uint64 start-offset
uint64 length
uint32 block-size
handle
'handle' is an open file handle returned by SSH_FXP_OPEN. If
'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST
return SSH_FX_INVALID_HANDLE. If ACE4_READ_DATA MUST was not
included when the file was opened, the server MUST return
STATUS_PERMISSION_DENIED.
If this file handle was opened in TEXT mode, the check must be
performed on the data as it would be sent on the wire.
hash-algorithm-list
A comma seperated list of hash alogirthms the client is willing to
accept for this operation. The server MUST pick the first hash on
the list that it supports.
Currently supported algorithms are "md5", "sha1", "sha224",
"sha256", "sha384", "sha512", and "crc32". Additional algorithms
may be added by following the DNS extensibility naming convention
outlined in [I-D.ietf-secsh-architecture].
MD5 is described in [RFC1321]. SHA-1, SHA-224, SHA-256, SHA-384,
and SHA-512 are decribed in [FIPS-180-2]. crc32 is described in
[ISO.3309.1991], and is the same algorithm used in [RFC1510]
start-offset
The starting offset of the data to include in the hash.
length
The length of data to include in the hash. If length is zero, all
the data from start-offset to the end-of-file should be included.
block-size
An independant hash MUST be computed over ever block in the file.
The size of blocks is specified by block-size. The block-size
MUST NOT be smaller than 256 bytes. If the block-size is 0, then
only one hash, over the entire range MUST be made.
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 "check-file"
string hash-algo-used
byte hash[n][block-count]
hash-algo-used
The hash algorithm that was actually used.
hash
The computed hashes. The hash algorithm used determines the size
of n. The number of block-size chunks of data in the file
determines block-count. The hashes are placed in the packet one
after another, with no decoration.
Note that if the length of the range is not an even multiple of
block-size, the last hash will have been computer over only the
remainder of the range instead of a full block.
9.2 Querying Available Space 9.2 Querying Available Space
The following extension provides a way to discover the available The following extension provides a way to discover the available
space for an arbitrary path. space for an arbitrary path.
byte SSH_FXP_EXTENDED byte SSH_FXP_EXTENDED
uint32 request-id uint32 request-id
string "space-available" string "space-available"
string path [UTF-8] string path [UTF-8]
path path
'path' for which the available space should be reported. This 'path' for which the available space should be reported. This
'path' is not required to be the mount point path, but MAY be a 'path' is not required to be the mount point path, but MAY be a
directory or file contained within the mount. directory or file contained within the mount.
The reply to the request is as follows:
byte SSH_FXP_EXTENDED_REPLY byte SSH_FXP_EXTENDED_REPLY
uint32 request-id uint32 request-id
uint64 total-space-on-device uint64 bytes-on-device
uint64 unused-on-device uint64 unused-bytes-on-device
uint64 total-space-available-to-user uint64 bytes-available-to-user
uint64 unused-space-available-to-user uint64 unused-bytes-available-to-user
uint32 bytes-per-allocation-unit
total-space-on-device bytes-on-device
The total amount of storage space on the device which stores The total number of bytes on the device which stores 'path', both
'path', both used and unused, or 0 if unknown. used and unused, or 0 if unknown.
unused-space-on-device unused-bytes-on-device
The total amount of unused storage availabe on the device which The total number of unused bytes availabe on the device which
stores 'path', or 0 if unknown. stores 'path', or 0 if unknown.
total-space-available-to-user bytes-available-to-user
The total amount of storage space, both used and unused, available The total number of bytes, both used and unused, available to the
to the authenticated user on the device which stores 'path', or 0 authenticated user on the device which stores 'path', or 0 if
if unknown. unknown.
unused-space-on-device unused-bytes-available-to-user
The total amount of unused storage available to the authenticated The total number of unused bytes available to the authenticated
user on the device which stores 'path', or 0 if unknown. user on the device which stores 'path', or 0 if unknown.
bytes-per-allocation-unit
The number of bytes in each allocation unit on the device, or in
other words, the minimum number of bytes that a file allocation
size can grow or shrink by. If the server does not know this
information, or the file-system in use does not use allocation
block, this value MUST be 0.
9.3 Querying User Home Directory
Many users are used to being able to type '~' as an alias for their
home directory, or ~username as an alias for another user's home
directory. To support this feature, a server MAY support following
extension.
byte SSH_FXP_EXTENDED
uint32 request-id
string "home-directory"
string username [UTF-8]
username
Username whose home directory path is being requested. An empty
string implies the current user.
The reply to the request is either a SSH_FXP_STATUS packet or the
following extended reply:
byte SSH_FXP_EXTENDED_REPLY
uint32 request-id
string "home-directory"
string absolute-pathname
absolute-pathname
Absolute pathname of the specified user's home directory.
10. Implementation Considerations 10. Implementation Considerations
In order for this protocol to perform well, especially over high In order for this protocol to perform well, especially over high
latency networks, multiple read and write requests should be queued latency networks, multiple read and write requests should be queued
to the server. to the server.
The data size of requests should match the maximum packet size for The data size of requests should match the maximum packet size for
the next layer up in the protocol chain. the next layer up in the protocol chain.
When implemented over ssh, the best performance should be achieved When implemented over ssh, the best performance should be achieved
skipping to change at page 49, line 19 skipping to change at page 51, line 11
features. Such security issues are left to the underlying transport features. Such security issues are left to the underlying transport
protocol, except to note that if this is not the case, an attacker protocol, except to note that if this is not the case, an attacker
could manipulate files on the server at will and thus wholly could manipulate files on the server at will and thus wholly
compromise the server. 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 [6]. protocol, typically using [I-D.ietf-secsh-userauth].
Extreme care must be used when interpreting file handle strings. In Extreme care must be used when interpreting file handle strings. In
particular, care must be taken that a file handle string is valid in particular, care must be taken that a file handle string is valid in
the context of a given SFTP session. For example, the sftp server the context of a given 'file-share' session. For example, the
daemon may have files which it has opened for its own purposes, and 'file-share' server daemon may have files which it has opened for its
the client must not be able to access these files by specifying an own purposes, and the client must not be able to access these files
arbitrary file handle string. by specifying an arbitrary file handle string.
The permission field of the attrib structure (Section 6.6) may The permission field of the attrib structure (Section 6.6) may
include the SUID, SGID, and SVTX (sticky) bits. Clients should use include the SUID, SGID, and SVTX (sticky) bits. Clients should use
extreme caution when setting these bits on either remote or local 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 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.) not necessarily imply that it should be SUID on the local system.)
Filesystems often contain entries for objects that are not files at Filesystems often contain entries for objects that are not files at
all, but are rather devices. For example, it may be possible to all, but are rather devices. For example, it may be possible to
access serial ports, tape devices, or named pipes using this access serial ports, tape devices, or named pipes using this
skipping to change at page 51, line 12 skipping to change at page 52, line 13
been numerous reported security bugs where a ".." in a path name has been numerous reported security bugs where a ".." in a path name has
allowed access outside the intended area. allowed access outside the intended area.
12. Changes from Previous Protocol Versions 12. Changes from Previous Protocol Versions
The SSH File Transfer Protocol has changed over time, before its 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.
12.1 Changes Between Versions 6 and 5 12.1 Changes Between Versions 6 and 5
********************* DO NOT IMPLEMENT ***********************
********************* DO NOT IMPLEMENT ***********************
***** *****
***** There will be more edits after IETF 61. *****
***** *****
********************* DO NOT IMPLEMENT ***********************
********************* DO NOT IMPLEMENT ***********************
o Add ability to negotiate version when client supports discontigous o Add ability to negotiate version when client supports discontigous
ranges of protocol version. ranges of protocol version.
o Add 'filename-charset' and the 'filename-translation-control' o Add 'filename-charset' and the 'filename-translation-control'
extensions to allow better support of servers that can't reliably extensions to allow better support of servers that can't reliably
translate to UTF-8. translate to UTF-8.
o Add DIR_NOT_EMPTY, NOT_A_DIRECTORY, INVALID_FILENAME and LINK_LOOP o Add DIR_NOT_EMPTY, NOT_A_DIRECTORY, INVALID_FILENAME LINK_LOOP,
error codes. CANNOT_DELETE, INVALID_PARAMETER, FILE_IS_A_DIRECTORY,
BYTE_RANGE_LOCK_CONFLICT, BYTE_RANGE_LOCK_REFUSED, DELETE_PENDING,
and FILE_CORRUPT error codes.
o Added space-available extension. o Added space-available extension.
o Added NOFOLLOW flag to open flags. o Added NOFOLLOW and DELETE_ON_CLOSE flag to open flags.
o Added allocation-size, text-hint, link-count, mime-type, and o Added allocation-size, text-hint, link-count, mime-type, and
untranslated-name fields to attrib structure. Add untranslated-name fields to attrib structure. Add
ATTR_FLAGS_TRANSLATION_ERR to the attrib-bits. ATTR_FLAGS_TRANSLATION_ERR to the attrib-bits.
o Add optional 'compose-path' and 'control-byte' to REALPATH; make
realpath's behaviour truly deterministic (i.e., MUST instead of
SHOULD.) Give clients the ability to compose path's without
understanding what is relative and what is absolute.
o Give SSH_FXP_DATA and SSH_FXP_NAME optional end-of-data-set flags,
which can help the client avoid a round trip during normal
operation.
o Changed the SYMLINK packet to be LINK and give it the ability to
create hard links. Also change it's packet number because many
implementation implemented SYMLINK with the arguments reversed.
Hopefully the new argument names make it clear which way is which.
o Clarify who should apply umask to posix mode bits (the client, not
the server.)
o Specify behavior for otherwise valid packets with excess data and
unrecognized packet types.
o Add home directory extension.
o Remove "#define" from symbol definitions to shorten line and help
us pass idnits.
12.2 Changes Between Versions 5 and 4 12.2 Changes Between Versions 5 and 4
Many of the changes between version 5 and version 4 are to better Many of the changes between version 5 and version 4 are to better
support the changes in version 4, and to better specify error support the changes in version 4, and to better specify error
conditions. conditions.
o Add "supported" extension to communicate features supported. o Add "supported" extension to communicate features supported.
o Clarify error handling when client requests unsupported feature. o Clarify error handling when client requests unsupported feature.
(For example, attempts to write an unsupported attribute.) (For example, attempts to write an unsupported attribute.)
skipping to change at page 55, line 9 skipping to change at page 54, line 32
13. Trademark Issues 13. 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.
14. References 14. References
14.1 Normative References 14.1 Normative References
[1] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
draft-ietf-secsh-architecture-16 (work in progress), June 2004. April 1992.
[2] Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol", [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
draft-ietf-secsh-transport-18 (work in progress), June 2004. Authentication Service (V5)", RFC 1510, September 1993.
[3] Ylonen, T., Kivinen, T., Rinne, T. and S. Lehtinen, "SSH [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Connection Protocol", draft-ietf-secsh-connect-19 (work in Beame, C., Eisler, M. and D. Noveck, "NFS version 4
progress), June 2004. Protocol", RFC 3010, December 2000.
[4] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, [I-D.ietf-secsh-architecture]
C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC Lonvick, C., "SSH Protocol Architecture",
3010, December 2000. Internet-Draft draft-ietf-secsh-architecture-22, March
2005.
[5] Institute of Electrical and Electronics Engineers, "Information [I-D.ietf-secsh-transport]
Technology - Portable Operating System Interface (POSIX) - Part Lonvick, C., "SSH Transport Layer Protocol",
1: System Application Program Interface (API) [C Language]", Internet-Draft draft-ietf-secsh-transport-24, March 2005.
IEEE Standard 1003.2, 1996.
[I-D.ietf-secsh-connect]
Lonvick, C., "SSH Connection Protocol",
Internet-Draft draft-ietf-secsh-connect-25, March 2005.
[IEEE.1003-1.1996]
Institute of Electrical and Electronics Engineers,
"Information Technology - Portable Operating System
Interface (POSIX) - Part 1: System Application Program
Interface (API) [C Language]", IEEE Standard 1003.2, 1996.
[FIPS-180-2]
National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", Federal Information Processing
Standards Publication 180-2, August 2002.
[ISO.3309.1991]
International Organization for Standardization,
"Information Technology - Telecommunications and
information exchange between systems - High-level data
link control (HDLC) procedures - Frame structure",
ISO Standard 3309, June 1991.
14.2 Informative References 14.2 Informative References
[6] Ylonen, T. and C. Lonvick, "SSH Authentication Protocol", [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
draft-ietf-secsh-userauth-21 (work in progress), June 2004. Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies",
RFC 1521, September 1993.
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
2246, January 1999. RFC 2246, January 1999.
[8] Alvestrand, H., "IETF Policy on Character Sets and Languages", [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[9] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail [I-D.ietf-secsh-userauth]
Extensions) Part One: Mechanisms for Specifying and Describing Lonvick, C., "SSH Authentication Protocol",
the Format of Internet Message Bodies", RFC 1521, September Internet-Draft draft-ietf-secsh-userauth-27, March 2005.
1993.
Author's Address Authors' Addresses
Joseph Galbraith Joseph Galbraith
VanDyke Software VanDyke Software
4848 Tramway Ridge Blvd 4848 Tramway Ridge Blvd
Suite 101 Suite 101
Albuquerque, NM 87111 Albuquerque, NM 87111
US US
Phone: +1 505 332 5700 Phone: +1 505 332 5700
EMail: galb-list@vandyke.com Email: galb-list@vandyke.com
Oskari Saarenmaa
F-Secure
Tammasaarenkatu 7
Helsinki 00180
FI
Email: oskari.saarenmaa@f-secure.com
Tatu Ylonen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
Email: ylo@ssh.com
Sami Lehtinen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
Email: sjl@ssh.com
Trademark notice
"ssh" is a registered trademark in the United States and/or other
countries.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 57, line 41 skipping to change at page 57, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment 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/