draft-ietf-secsh-filexfer-09.txt   draft-ietf-secsh-filexfer-10.txt 
Secure Shell Working Group J. Galbraith Secure Shell Working Group J. Galbraith
Internet-Draft VanDyke Software Internet-Draft VanDyke Software
Expires: December 12, 2005 O. Saarenmaa Expires: December 3, 2005 O. Saarenmaa
F-Secure F-Secure
T. Ylonen June 2005
S. Lehtinen
SSH Communications Security Corp
June 10, 2005
SSH File Transfer Protocol SSH File Transfer Protocol
draft-ietf-secsh-filexfer-09.txt draft-ietf-secsh-filexfer-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 38 skipping to change at page 1, line 35
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 December 12, 2005. This Internet-Draft will expire on December 3, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . 4 2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 The Use of 'stderr' in the server . . . . . . . . . . . . 4 3. Use with the SSH Connection Protocol . . . . . . . . . . . . . 4
3. General Packet Format . . . . . . . . . . . . . . . . . . . . 5 3.1. The Use of 'stderr' in the server . . . . . . . . . . . . 5
3.1 Request Synchronization and Reordering . . . . . . . . . . 6 4. General Packet Format . . . . . . . . . . . . . . . . . . . . 5
3.2 New data types defined by this document . . . . . . . . . 6 4.1. Request Synchronization and Reordering . . . . . . . . . . 6
3.3 Packet Types . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. New data types defined by this document . . . . . . . . . 7
4. Protocol Initialization . . . . . . . . . . . . . . . . . . . 9 4.3. Packet Types . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Client Initialization . . . . . . . . . . . . . . . . . . 9 5. Protocol Initialization . . . . . . . . . . . . . . . . . . . 9
4.2 Server Initialization . . . . . . . . . . . . . . . . . . 9 5.1. Client Initialization . . . . . . . . . . . . . . . . . . 9
4.3 Determining Server Newline Convention . . . . . . . . . . 10 5.2. Server Initialization . . . . . . . . . . . . . . . . . . 9
4.4 Vendor Id . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Determining Server Newline Convention . . . . . . . . . . 10
4.5 Supported Features . . . . . . . . . . . . . . . . . . . . 11 5.4. Supported Features . . . . . . . . . . . . . . . . . . . . 10
4.6 Version re-negotiation . . . . . . . . . . . . . . . . . . 13 5.5. Version re-negotiation . . . . . . . . . . . . . . . . . . 13
5. File Names . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. File Names . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 16 7. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 15
6.1 valid-attribute-flags . . . . . . . . . . . . . . . . . . 17 7.1. valid-attribute-flags . . . . . . . . . . . . . . . . . . 16
6.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.3. Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.4 allocation-size . . . . . . . . . . . . . . . . . . . . . 19 7.4. allocation-size . . . . . . . . . . . . . . . . . . . . . 18
6.5 Owner and Group . . . . . . . . . . . . . . . . . . . . . 19 7.5. Owner and Group . . . . . . . . . . . . . . . . . . . . . 18
6.6 Permissions . . . . . . . . . . . . . . . . . . . . . . . 20 7.6. Permissions . . . . . . . . . . . . . . . . . . . . . . . 19
6.7 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.7. Times . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.8 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.8. ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.9 attrib-bits and attrib-bits-valid . . . . . . . . . . . . 23 7.9. attrib-bits and attrib-bits-valid . . . . . . . . . . . . 21
6.10 text-hint . . . . . . . . . . . . . . . . . . . . . . . . 25 7.10. text-hint . . . . . . . . . . . . . . . . . . . . . . . . 24
6.11 mime-type . . . . . . . . . . . . . . . . . . . . . . . . 26 7.11. mime-type . . . . . . . . . . . . . . . . . . . . . . . . 24
6.12 link-count . . . . . . . . . . . . . . . . . . . . . . . . 26 7.12. link-count . . . . . . . . . . . . . . . . . . . . . . . . 25
6.13 untranslated-name . . . . . . . . . . . . . . . . . . . . 26 7.13. untranslated-name . . . . . . . . . . . . . . . . . . . . 25
6.14 Extended Attributes . . . . . . . . . . . . . . . . . . . 26 7.14. Extended Attributes . . . . . . . . . . . . . . . . . . . 25
7. Requests From the Client to the Server . . . . . . . . . . . . 26 8. Requests From the Client to the Server . . . . . . . . . . . . 25
7.1 Opening and Closing Files and Directories . . . . . . . . 27 8.1. Opening and Closing Files and Directories . . . . . . . . 25
7.1.1 Opening a File . . . . . . . . . . . . . . . . . . . . 27 8.1.1. Opening a File . . . . . . . . . . . . . . . . . . . . 26
7.1.2 Opening a Directory . . . . . . . . . . . . . . . . . 32 8.1.2. Opening a Directory . . . . . . . . . . . . . . . . . 31
7.1.3 Closing Handles . . . . . . . . . . . . . . . . . . . 33 8.1.3. Closing Handles . . . . . . . . . . . . . . . . . . . 32
7.2 Reading and Writing . . . . . . . . . . . . . . . . . . . 33 8.2. Reading and Writing . . . . . . . . . . . . . . . . . . . 32
7.2.1 Reading Files . . . . . . . . . . . . . . . . . . . . 33 8.2.1. Reading Files . . . . . . . . . . . . . . . . . . . . 32
7.2.2 Reading Directories . . . . . . . . . . . . . . . . . 34 8.2.2. Reading Directories . . . . . . . . . . . . . . . . . 33
7.2.3 Writing Files . . . . . . . . . . . . . . . . . . . . 35 8.2.3. Writing Files . . . . . . . . . . . . . . . . . . . . 34
7.3 Removing and Renaming Files . . . . . . . . . . . . . . . 35 8.3. Removing and Renaming Files . . . . . . . . . . . . . . . 34
7.4 Creating and Deleting Directories . . . . . . . . . . . . 37 8.4. Creating and Deleting Directories . . . . . . . . . . . . 36
7.5 Retrieving File Attributes . . . . . . . . . . . . . . . . 37 8.5. Retrieving File Attributes . . . . . . . . . . . . . . . . 36
7.6 Setting File Attributes . . . . . . . . . . . . . . . . . 38 8.6. Setting File Attributes . . . . . . . . . . . . . . . . . 37
7.7 Dealing with Links . . . . . . . . . . . . . . . . . . . . 39 8.7. Dealing with Links . . . . . . . . . . . . . . . . . . . . 38
7.8 Byte-range locks . . . . . . . . . . . . . . . . . . . . . 40 8.8. Byte-range locks . . . . . . . . . . . . . . . . . . . . . 39
7.9 Canonicalizing the Server-Side Path Name . . . . . . . . . 42 8.9. Canonicalizing the Server-Side Path Name . . . . . . . . . 40
7.9.1 Best Practice for Dealing with Paths . . . . . . . . . 43 8.9.1. Best Practice for Dealing with Paths . . . . . . . . . 42
8. Responses from the Server to the Client . . . . . . . . . . . 44 9. Responses from the Server to the Client . . . . . . . . . . . 43
8.1 Status Response . . . . . . . . . . . . . . . . . . . . . 44 9.1. Status Response . . . . . . . . . . . . . . . . . . . . . 43
8.2 Handle Response . . . . . . . . . . . . . . . . . . . . . 49 9.2. Handle Response . . . . . . . . . . . . . . . . . . . . . 48
8.3 Data Response . . . . . . . . . . . . . . . . . . . . . . 49 9.3. Data Response . . . . . . . . . . . . . . . . . . . . . . 48
8.4 Name Response . . . . . . . . . . . . . . . . . . . . . . 50 9.4. Name Response . . . . . . . . . . . . . . . . . . . . . . 49
8.5 Attrs Response . . . . . . . . . . . . . . . . . . . . . . 50 9.5. Attrs Response . . . . . . . . . . . . . . . . . . . . . . 50
9. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 51 10. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.1 File Hashing . . . . . . . . . . . . . . . . . . . . . . . 52 11. Implementation Considerations . . . . . . . . . . . . . . . . 51
9.1.1 Checking File Contents: v5 extension . . . . . . . . . 53 12. Security Considerations . . . . . . . . . . . . . . . . . . . 51
9.1.2 Checking File Contents . . . . . . . . . . . . . . . . 54 13. Changes from Previous Protocol Versions . . . . . . . . . . . 53
9.2 Querying Available Space . . . . . . . . . . . . . . . . . 56 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.3 Querying User Home Directory . . . . . . . . . . . . . . . 57 14.1. Normative References . . . . . . . . . . . . . . . . . . . 53
10. Implementation Considerations . . . . . . . . . . . . . . . 57 14.2. Informative References . . . . . . . . . . . . . . . . . . 53
11. Security Considerations . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
12. Changes from Previous Protocol Versions . . . . . . . . . . 59 Intellectual Property and Copyright Statements . . . . . . . . . . 56
12.1 Changes Between Versions 6 and 5 . . . . . . . . . . . . . 59
12.2 Changes Between Versions 5 and 4 . . . . . . . . . . . . . 60
12.3 Changes Between Versions 4 and 3 . . . . . . . . . . . . . 61
12.4 Changes Between Versions 3 and 2 . . . . . . . . . . . . . 61
12.5 Changes Between Versions 2 and 1 . . . . . . . . . . . . . 61
12.6 Changes Between Versions 1 and 0 . . . . . . . . . . . . . 61
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 62
13.1 Normative References . . . . . . . . . . . . . . . . . . . 62
13.2 Informative References . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . . 65
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 [I-D.ietf-secsh-architecture], and that the server has channel in [I-D.ietf-secsh-architecture], and that the server has
skipping to change at page 4, line 34 skipping to change at page 4, line 34
The packet format descriptions in this specification follow the The packet format descriptions in this specification follow the
notation presented in [I-D.ietf-secsh-architecture]. 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 [RFC2246] 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. Acknowledgements
This document owes it's initial creation and protocol design to Tatu
Ylonen and Sami Lehtinen of SSH Communications Security Corp.
We express our gratitude to them for their initial work on this
protocol.
3. 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 as a subsystem as described in [I-D.ietf-secsh-connect] in be used as a subsystem as described in [I-D.ietf-secsh-connect] in
the section "Starting a Shell or a Command". The subsystem name used the section "Starting a Shell or a Command". The subsystem name used
with this protocol is "sftp". with this protocol is "sftp".
2.1 The Use of 'stderr' in the server 3.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 ([I-D.ietf-secsh-connect]), 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 4. 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 ...
'length' 'length'
skipping to change at page 6, line 18 skipping to change at page 6, line 33
There is no limit on the number of outstanding (non-acknowledged) There is no limit on the number of outstanding (non-acknowledged)
requests that the client may send to the server. In practice this is requests that the client may send to the server. In practice this is
limited by the buffering available on the data stream and the queuing limited by the buffering available on the data stream and the queuing
performed by the server. If the server's queues are full, it should performed by the server. If the server's queues are full, it should
not read any more data from the stream, and flow control will prevent not read any more data from the stream, and flow control will prevent
the client from sending more requests. Note, however, that while the client from sending more requests. Note, however, that while
there is no restriction on the protocol level, the client's API may there is no restriction on the protocol level, the client's API may
provide a limit in order to prevent infinite queuing of outgoing provide a limit in order to prevent infinite queuing of outgoing
requests at the client. requests at the client.
3.1 Request Synchronization and Reordering 4.1. Request Synchronization and Reordering
The protocol and implementations MUST process requests relating to The protocol and implementations MUST process requests relating to
the same file in the order in which they are received. In other the same file in the order in which they are received. In other
words, if an application submits multiple requests to the server, the words, if an application submits multiple requests to the server, the
results in the responses will be the same as if it had sent the results in the responses will be the same as if it had sent the
requests one at a time and waited for the response in each case. For requests one at a time and waited for the response in each case. For
example, the server may process non-overlapping read/write requests example, the server may process non-overlapping read/write requests
to the same file in parallel, but overlapping reads and writes cannot to the same file in parallel, but overlapping reads and writes cannot
be reordered or parallelized. However, there are no ordering be reordered or parallelized. However, there are no ordering
restrictions on the server for processing requests from two different restrictions on the server for processing requests from two different
file transfer connections. The server may interleave and parallelize file transfer connections. The server may interleave and parallelize
them at will. them at will.
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 receive responses to multiple overlapped
requests out of order. requests out of order.
3.2 New data types defined by this document 4.2. New data types defined by this document
This document defines these data types in addition to those defined This document defines these data types in addition to those defined
in [I-D.ietf-secsh-architecture]. in [I-D.ietf-secsh-architecture].
uint16 uint16
Represents a 16-bit unsigned integer. Stored as 2 bytes in the Represents a 16-bit unsigned integer. Stored as 2 bytes in the
order of decreasing significance (network byte order). order of decreasing significance (network byte order).
int64 int64
Represents a 64-bit signed integer. Stored using two's Represents a 64-bit signed integer. Stored using two's
skipping to change at page 7, line 23 skipping to change at page 7, line 36
string extension-data string extension-data
'extension-name' is the name of a protocol extension. Extensions 'extension-name' is the name of a protocol extension. Extensions
not defined by IETF CONSENSUS MUST follow the the DNS not defined by IETF CONSENSUS MUST follow the the DNS
extensibility naming convention outlined in [I-D.ietf-secsh- extensibility naming convention outlined in [I-D.ietf-secsh-
architecture]. architecture].
'extension-data' is any data specific to the extension, and MAY be 'extension-data' is any data specific to the extension, and MAY be
zero length if the extension has no data. zero length if the extension has no data.
3.3 Packet Types 4.3. Packet Types
The following values are defined for packet types. The following values are defined for packet types.
SSH_FXP_INIT 1 SSH_FXP_INIT 1
SSH_FXP_VERSION 2 SSH_FXP_VERSION 2
SSH_FXP_OPEN 3 SSH_FXP_OPEN 3
SSH_FXP_CLOSE 4 SSH_FXP_CLOSE 4
SSH_FXP_READ 5 SSH_FXP_READ 5
SSH_FXP_WRITE 6 SSH_FXP_WRITE 6
SSH_FXP_LSTAT 7 SSH_FXP_LSTAT 7
skipping to change at page 9, line 4 skipping to change at page 9, line 4
meaning of these reserved types. It is suggested that the actual meaning of these reserved types. It is suggested that the actual
value to be used also be negotiated, since this will prevent value to be used also be negotiated, since this will prevent
collision among multiple uncoordinated extensions. collision among multiple uncoordinated extensions.
The server MUST respond with SSH_FXP_STATUS(SSH_FX_OP_UNSUPPORTED) if The server MUST respond with SSH_FXP_STATUS(SSH_FX_OP_UNSUPPORTED) if
it receives a packet it does not recognize. it receives a packet it does not recognize.
The use of additional packet types in the non-extension range MUST be The use of additional packet types in the non-extension range MUST be
introduced through IETF consensus. New packet types to be sent from introduced through IETF consensus. New packet types to be sent from
the client to the server MAY be introduced without changing the the client to the server MAY be introduced without changing the
protocol version (Section 4). Because the client has no way to protocol version (Section 5). Because the client has no way to
respond to unrecognized packet types, new packet types to be sent respond to unrecognized packet types, new packet types to be sent
from the server to the client the client MUST not used unless the from the server to the client the client MUST not used unless the
protocol version is changed or the client has negotiated to received protocol version is changed or the client has negotiated to received
them. This negotiation MAY be explicit, through the use of them. This negotiation MAY be explicit, through the use of
extensions, or MAY be implicit, by the client itself using a packet extensions, or MAY be implicit, by the client itself using a packet
type not defined above. type not defined above.
4. Protocol Initialization 5. Protocol Initialization
When the file transfer protocol starts, the client first sends a When the file transfer protocol starts, the client first sends a
SSH_FXP_INIT (including its version number) packet to the server. SSH_FXP_INIT (including its version number) packet to the server.
The 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 that particular version of the should from then on adhere to that particular version of the
protocol. 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.
Note that these two packets DO NOT contain a request id. These are Note that these two packets DO NOT contain a request id. These are
the only such packets in the protocol. the only such packets in the protocol.
4.1 Client Initialization 5.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' is the version number of the client. If the client wishes 'version' is the version number of the client. If the client wishes
to interoperate with servers that support discontiguous version to interoperate with servers that support discontinuous version
numbers it SHOULD send '3', and then use the 'version-select' numbers it SHOULD send '3', and then use the 'version-select'
extension (see below.) Otherwise, this value is '6' for this version extension (see below.) Otherwise, this value is '6' for this version
of the protocol. of the protocol.
4.2 Server Initialization 5.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-pair extensions[0..n] 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.
'extensions' is 0 or more extension-pairs (Section 3.2). 'extensions' is 0 or more extension-pairs (Section 4.2).
Implementations MUST silently ignore any extensions whose names they Implementations MUST silently ignore any extensions whose names they
do not recognize. do not recognize.
4.3 Determining Server Newline Convention 5.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_ACCESS_TEXT_MODE file open flag (Section 7.1.1) makes it The SSH_FXF_ACCESS_TEXT_MODE file open flag (Section 8.1.1) makes it
possible to request that the server translate a file to a 'canonical' possible to request that the server translate a file to a 'canonical'
wire format. This format uses CRLF as the line separator. wire format. This format uses CRLF as the line separator.
Servers for systems using other conventions MUST translate to and Servers for systems using other conventions MUST translate to and
from the canonical form. from 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.
skipping to change at page 10, line 39 skipping to change at page 10, line 39
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.
In particular, if the newline sequence being used is the canonical In particular, if the newline sequence being used is the canonical
CRLF sequence, a lone CR or a lone LF SHOULD be written through CRLF sequence, a lone CR or a lone LF SHOULD be written through
without change. without change.
4.4 Vendor Id 5.4. Supported Features
It is often necessary to detect the version of the server so that
bugs can be worked around. This extension allows the client to do
so. (It may also be sent by the client using an EXTENDED request.)
string "vendor-id"
string vendor-structure
string vendor-name
string product-name
string product-version
uint64 product-build-number
vendor-name
Arbitrary name identifying the maker of the product.
product-name
Arbitrary name identifying the product.
product-name
Arbitrary string identifying the version of the product.
product-build-number
A build-number for the product, such that if a bug is fixed in
build-number 'x', it can be assumed that (barring regression in
the product) it is fixed in all build-numbers > 'x'.
4.5 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. The following extension facilitates clients being able to specified. The following extension facilitates clients being able to
use the maximum available feature set, and yet not be overly burdened use the maximum available feature set, and yet not be overly burdened
by dealing with SSH_FX_OP_UNSUPPORTED status codes. All servers MUST by dealing with SSH_FX_OP_UNSUPPORTED status codes. All servers MUST
include as part of their version packet. include as part of their version packet.
string "supported2" 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 supported-access-mask
uint32 max-read-size uint32 max-read-size
uint16 supported-open-block-masks uint16 supported-open-block-vector
uint16 supported-block-masks uint16 supported-block-vector
uint32 attrib-extension-count uint32 attrib-extension-count
string attrib-extension-names[attrib_extension-count] string attrib-extension-names[attrib_extension-count]
uint32 extension-count uint32 extension-count
string extension-names[extension-count] string extension-names[extension-count]
Note that the name "supported2" is used here to avoid conflict with Note that the name "supported2" is used here to avoid conflict with
the slightly different "supported" extension that was previously the slightly different "supported" extension that was previously
used. used.
supported-attribute-mask supported-attribute-mask
This mask MAY by applied to the 'File Attributes' valid-attribute- This mask MAY by applied to the 'File Attributes' valid-attribute-
flags field (Section 6.1) to ensure that no unsupported attributes flags field (Section 7.1) to ensure that no unsupported attributes
are present during a operation which writes attributes. are present during a operation which writes 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 7.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 8.1.1) flags field.
supported-access-mask supported-access-mask
This mask may be applied to the ace-mask field of an ACL. This mask may be applied to the ace-mask field of an ACL.
This mask SHOULD NOT be applied to the desired-access field of the This mask SHOULD NOT be applied to the desired-access field of the
SSH_FXP_OPEN (Section 7.1.1) request. Doing so will simply result SSH_FXP_OPEN (Section 8.1.1) request. Doing so will simply result
in not requesting the access required by the client. In this in not requesting the access required by the client. In this
case, the server is responible for translating the clients case, the server is responsible for translating the clients
requested access to a mode it supports that is sufficient to grant requested access to a mode it supports that is sufficient to grant
all access requested by the client. all access requested by the client.
max-read-size max-read-size
This is the maximum read size that the server guarantees to This is the maximum read size that the server guarantees to
complete. For example, certain embedded server implementations complete. For example, certain embedded server implementations
complete only the first 4K of a read, even if there is additional complete only 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 for max-read-size, it If the server specifies a non-zero value for max-read-size, it
MUST return the requested number of bytes for reads that are less MUST return the requested number of bytes for reads that are less
than or equal to the value, unless it encounters EOF or an ERROR. than or equal to the value, unless it encounters EOF or an ERROR.
The server MAY use this value to express that it is willing to The server MAY use this value to express that it is willing to
handle very large read requests, in excess of the standard 34000 handle very large read requests, in excess of the standard 34000
bytes specfied in Section 3. bytes specified in Section 4.
supported-open-block-masks supported-open-block-vector
supported-block-masks supported-block-vector
16-bit masks specifying which combinations of blocking flags are 16-bit masks specifying which combinations of blocking flags are
supported. Each bit corresponds to one combination of the supported. Each bit corresponds to one combination of the
SSH_FXF_ACCESS_BLOCK_READ, SSH_FXF_ACCESS_BLOCK_WRITE, SSH_FXF_ACCESS_BLOCK_READ, SSH_FXF_ACCESS_BLOCK_WRITE,
SSH_FXF_ACCESS_BLOCK_DELETE, and SSH_FXF_ACCESS_BLOCK_ADVISORY SSH_FXF_ACCESS_BLOCK_DELETE, and SSH_FXF_ACCESS_BLOCK_ADVISORY
bits from Section 7.1.1.3, with a set bit corresponding to a bits from Section 7.1.1.3, with a set bit corresponding to a
supported combination and a clear bit an unsupported combination. supported combination and a clear bit an unsupported combination.
The index of a bit, bit zero being the least significant bit, The index of a bit, bit zero being the least significant bit,
viewed as a four-bit number, corresponds to a combination of flag viewed as a four-bit number, corresponds to a combination of flag
bits, shifted right so that BLOCK_READ is the least significant bits, shifted right so that BLOCK_READ is the least significant
bit. The combination `no blocking flags' MUST be supported, so bit. The combination `no blocking flags' MUST be supported, so
the low bit will always be set. the low bit will always be set.
For example, a server supporting only the classic advisory read For example, a server supporting only the classic advisory read
(shared) and write (exclusive) locks would set the bits (shared) and write (exclusive) locks would set the bits
corresponding to READ+WRITE+ADVISORY, 0b1011, and WRITE+ADVISORY, corresponding to READ+WRITE+ADVISORY, 0b1011, and WRITE+ADVISORY,
0b1010, plus the always-set bit 0b0000, giving a mask value of 0b1010, plus the always-set bit 0b0000, giving a mask value of
0b0000110000000001, or 0x0c01; a server supporting no locking at 0b0000110000000001, or 0x0c01; a server supporting no locking at
all would set only bit zero, giving 0x0001. all would set only bit zero, giving 0x0001.
'supported-open-block-masks' applies to the SSH_FXP_OPEN 'supported-open-block-masks' applies to the SSH_FXP_OPEN
(Section 7.1.1) flags field. 'supported-block-masks' applies to (Section 8.1.1) flags field. 'supported-block-masks' applies to
the SSH_FXF_BLOCK request. the SSH_FXF_BLOCK request.
attrib-extension-count attrib-extension-count
Count of extension names in the attrib-extension array. Count of extension names in the attrib-extension-names array.
attrib-extension-names attrib-extension-names
Names of extensions that can be used in an ATTRS (Section 6.14) Names of extensions that can be used in an ATTRS (Section 7.14)
structure. structure.
extension-count extension-count
Count of extension names in the attrib-extension array. Count of extension names in the extension-names array.
extension-names extension-names
Names of extensions that can be used with the SSH_FXP_EXTEND Names of extensions that can be used with the SSH_FXP_EXTEND
(Section 9) packet. (Section 10) packet.
Naturally, if a given attribute field, attribute mask bit, open flag, Naturally, if a given attribute field, attribute mask bit, open flag,
or extension is required for correct operation, the client MUST or extension is required for correct operation, the client MUST
either not allow the bit to be masked off, or MUST fail the operation either not allow the bit to be masked off, or MUST fail the operation
gracefully without sending the request to the server. gracefully without sending the request to the server.
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.6 Version re-negotiation 5.5. Version re-negotiation
If the server supports other versions than what was negotiated, it If the server supports other versions than what was negotiated, it
may wish to send the 'versions' extension to inform the client of may wish to send the 'versions' extension to inform the client of
this fact. The client may then optionally choose to use one of the this fact. The client may then optionally choose to use one of the
other versions supported. other versions supported.
string "versions" string "versions"
string comma-separated-versions string comma-separated-versions
'comma-separated-versions' is a string of comma separated version 'comma-separated-versions' is a string of comma separated version
skipping to change at page 14, line 45 skipping to change at page 14, line 15
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, and any invalid request results in a channel close. MUST succeed, and any invalid request results in a channel close.
Since the request is the first request, it is not possible for the Since the request is the first request, it is not possible for the
server to have already sent responses conforming to the old version. server to have already sent responses conforming to the old version.
Typically, the client SHOULD NOT down-grade the protocol version Typically, the client SHOULD NOT down-grade the protocol version
using this extension; however, it is not forbidden to do so. One using this extension; however, it is not forbidden to do so. One
reason a client might do so is to work around a buggy implementation. reason a client might do so is to work around a buggy implementation.
5. File Names 6. 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
protocol. protocol.
Servers SHOULD interpret a path name component ".." (Section 11) as Servers SHOULD interpret a path name component ".." (Section 12) as
referring to the parent directory, and "." as referring to the referring to the parent directory, and "." as referring to the
current directory. current directory.
An empty path name is valid, and it refers to the user's default An empty path name is valid, and it refers to the user's default
directory (usually the user's home directory). directory (usually the user's home directory).
Otherwise, no syntax is defined for file names by this specification. Otherwise, no syntax is defined for file names by this specification.
Clients should not make any other assumptions; however, they can Clients should not make any other assumptions; however, they can
splice path name components returned by SSH_FXP_READDIR together splice path name components returned by SSH_FXP_READDIR together
using a slash ('/') as the separator, and that will work as expected. using a slash ('/') as the separator, and that will work as expected.
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 preferred encoding for filenames is UTF-8. This is consistent
with IETF Policy on Character Sets and Languages [RFC2277] 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.
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 reversible. 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
skipping to change at page 16, line 31 skipping to change at page 15, line 49
'filename-charset' extension, the status MUST be SUCCESS. Otherwise, 'filename-charset' extension, the status MUST be SUCCESS. Otherwise,
the status MUST be SSH_FX_OP_UNSUPPORTED. the status MUST be SSH_FX_OP_UNSUPPORTED.
When UTF-8 is sent, the shortest valid UTF-8 encoding of the UNICODE 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 data MUST be used. The server is responsible for converting the
UNICODE data to whatever canonical form it requires. For example, if UNICODE data to whatever canonical form it requires. For example, if
the server requires that precomposed characters always be used, the the server requires that precomposed characters always be used, the
server MUST NOT assume the filename as sent by the client has this server MUST NOT assume the filename as sent by the client has this
attribute, but must do this normalization itself. attribute, but must do this normalization itself.
6. File Attributes 7. File Attributes
A new compound data type, 'ATTRS', is defined for encoding file A new compound data type, 'ATTRS', is defined for encoding file
attributes. The same encoding is used both when returning file attributes. The same encoding is used both when returning file
attributes from the server and when sending file attributes to the attributes from the server and when sending file attributes to the
server. server.
uint32 valid-attribute-flags uint32 valid-attribute-flags
byte type always present byte type always present
uint64 size if flag SIZE uint64 size if flag SIZE
uint64 allocation-size if flag ALLOCATION_SIZE uint64 allocation-size if flag ALLOCATION_SIZE
string owner if flag OWNERGROUP string owner if flag OWNERGROUP
skipping to change at page 17, line 30 skipping to change at page 16, line 34
string acl if flag ACL string acl if flag ACL
uint32 attrib-bits if flag BITS uint32 attrib-bits if flag BITS
uint32 attrib-bits-valid if flag BITS uint32 attrib-bits-valid if flag BITS
byte text-hint if flag TEXT_HINT byte text-hint if flag TEXT_HINT
string mime-type if flag MIME_TYPE string mime-type if flag MIME_TYPE
uint32 link-count if flag LINK_COUNT uint32 link-count if flag LINK_COUNT
string untranslated-name if flag UNTRANSLATED_NAME string untranslated-name if flag UNTRANSLATED_NAME
uint32 extended-count if flag EXTENDED uint32 extended-count if flag EXTENDED
extended-pair extensions extended-pair extensions
6.1 valid-attribute-flags 7.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.
When writing attributes, the server SHOULD NOT modify attributes that When writing attributes, the server SHOULD NOT modify attributes that
skipping to change at page 18, line 26 skipping to change at page 17, line 31
SSH_FILEXFER_ATTR_MIME_TYPE 0x00001000 SSH_FILEXFER_ATTR_MIME_TYPE 0x00001000
SSH_FILEXFER_ATTR_LINK_COUNT 0x00002000 SSH_FILEXFER_ATTR_LINK_COUNT 0x00002000
SSH_FILEXFER_ATTR_UNTRANSLATED_NAME 0x00004000 SSH_FILEXFER_ATTR_UNTRANSLATED_NAME 0x00004000
SSH_FILEXFER_ATTR_CTIME 0x00008000 SSH_FILEXFER_ATTR_CTIME 0x00008000
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 7.2. Type
The type field is always present. The following types are defined: The type field is always present. The following types are defined:
SSH_FILEXFER_TYPE_REGULAR 1 SSH_FILEXFER_TYPE_REGULAR 1
SSH_FILEXFER_TYPE_DIRECTORY 2 SSH_FILEXFER_TYPE_DIRECTORY 2
SSH_FILEXFER_TYPE_SYMLINK 3 SSH_FILEXFER_TYPE_SYMLINK 3
SSH_FILEXFER_TYPE_SPECIAL 4 SSH_FILEXFER_TYPE_SPECIAL 4
SSH_FILEXFER_TYPE_UNKNOWN 5 SSH_FILEXFER_TYPE_UNKNOWN 5
SSH_FILEXFER_TYPE_SOCKET 6 SSH_FILEXFER_TYPE_SOCKET 6
SSH_FILEXFER_TYPE_CHAR_DEVICE 7 SSH_FILEXFER_TYPE_CHAR_DEVICE 7
SSH_FILEXFER_TYPE_BLOCK_DEVICE 8 SSH_FILEXFER_TYPE_BLOCK_DEVICE 8
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 7.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. This the file, or in other words, the location of the end-of-file. This
attribute MUST NOT be present during file creation. attribute MUST NOT be present during file creation.
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. extended or truncated to the specified size.
Files opened with the SSH_FXF_ACCESS_TEXT flag may have a size that Files opened with the SSH_FXF_ACCESS_TEXT flag may have a size that
is greater or less than the value of the size field. The server MAY is greater or less than the value of the size field. The server MAY
fail setstat operations specifying size for files opened with the fail setstat operations specifying size for files opened with the
SSH_FXF_ACCESS_TEXT flag. SSH_FXF_ACCESS_TEXT flag.
6.4 allocation-size 7.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 field MAY be less than the 'size' field file consumes on disk. This field MAY be less than the 'size' field
if the file is 'sparse' (Section 6.9). if the file is 'sparse' (Section 7.9).
When present during file creation, the file SHOULD be created and the When present during file creation, the file SHOULD be created and the
specified number of bytes pre-allocated. If the pre-allocation specified number of bytes preallocated. If the preallocation fails,
fails, the file should be removed (if it was created) and an error the file should be removed (if it was created) and an error returned.
returned.
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. The 'size' of the be extended or truncated to the specified size. The 'size' of the
file may be affected by this operation. If the operation succeeds, file may be affected by this operation. If the operation succeeds,
the 'size' should be the minimum of the 'size' before the operation the 'size' should be the minimum of the 'size' before the operation
and the new 'allocation-size'. and the new 'allocation-size'.
Querying the 'allocation-size' after setting it MUST return a value Querying the 'allocation-size' after setting it MUST return a value
that is greater-than or equal to the value set, but it MAY not return that is greater-than or equal to the value set, but it MAY not return
the precise value set. the precise value set.
If both 'size' and 'allocation-size' are set during a setstat If both 'size' and 'allocation-size' are set during a setstat
operation, and 'allocation-size' is less than 'size', the server MUST operation, and 'allocation-size' is less than 'size', the server MUST
return SSH_FX_INVALID_PARAMETER. return SSH_FX_INVALID_PARAMETER.
6.5 Owner and Group 7.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 [RFC3010]. is the form used by NFS v4. See NFS version 4 Protocol [RFC3010].
The 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
skipping to change at page 20, line 13 skipping to change at page 19, line 18
value cannot be translated, it may still be useful. In the case of a value cannot be translated, it may still be useful. In the case of a
client, the attribute string may be used for local display of client, the attribute string may be used for local display of
ownership. ownership.
user@localhost represents a user in the context of the server. 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 during a modification operation. field during a modification operation.
6.6 Permissions 7.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 [IEEE.1003-1.1996]. 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.
S_IRUSR 0000400 (octal) S_IRUSR 0000400 (octal)
S_IWUSR 0000200 S_IWUSR 0000200
skipping to change at page 20, line 41 skipping to change at page 19, line 46
S_ISUID 0004000 S_ISUID 0004000
S_ISGID 0002000 S_ISGID 0002000
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 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 set the mode bits as specified by the client. The client MUST apply
an appropriate 'umask' to the mode bits before sending them. an appropriate 'umask' to the mode bits before sending them.
6.7 Times 7.7. Times
The 'atime' field contains the last access time of the file. Many The 'atime' field contains the last access time of the file. Many
operating systems either don't have this field, only optionally operating systems either don't have this field, only optionally
maintain it, or maintain it with less resolution than other fields. maintain it, or maintain it with less resolution than other fields.
The 'mtime' contains the last time the file was written. The 'mtime' contains the last time the file was written.
'createtime' contains the creation time of the file. 'createtime' contains the creation time of the file.
'ctime' contains the last time the file attrbutes were changed. The 'ctime' contains the last time the file attributes were changed. The
exact meaning of this field depends on the server. exact meaning of this field depends on the server.
All times are represented as seconds from Jan 1, 1970 in UTC. A All times are represented as seconds from Jan 1, 1970 in UTC. A
negative value indicates number of seconds before Jan 1, 1970. In 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 one- representation. For example, if the time to be represented is one-
half second before 0 hour January 1, 1970, the seconds field would half second before 0 hour January 1, 1970, the seconds field would
have a value of negative one (-1) and the nseconds fields would have have a value of negative one (-1) and the nseconds fields would have
a value of one-half second (500000000). Values greater than 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 7.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 [RFC3010]. 5.9 of NFS version 4 Protocol [RFC3010].
bool acl-present
uint32 ace-count uint32 ace-count
repeated ace-count times: repeated ace-count times:
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]
If the 'acl-present' flag is not set, it indicates that the file does
not have an ACL. In this case the 'ace-count' field is omitted and
implicitly zero. This condition indicates that the server both
supports ACLs and that it checked the file and found no ACL for this
file. This is distinct from the case of SSH_FILEXFER_ATTR_ACL not
being present in the attrib flags. If SSH_FILEXFER_ATTR_ACL is not
present, the client can not deduce whether the server does not
support ACLs, did not check the ACL (because doing so was expensive),
or had some other reason for omitting the data.
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 [RFC3010]: 4 Protocol [RFC3010]:
ACE4_ACCESS_ALLOWED_ACE_TYPE 0x00000000 ACE4_ACCESS_ALLOWED_ACE_TYPE 0x00000000
ACE4_ACCESS_DENIED_ACE_TYPE 0x00000001 ACE4_ACCESS_DENIED_ACE_TYPE 0x00000001
ACE4_SYSTEM_AUDIT_ACE_TYPE 0x00000002 ACE4_SYSTEM_AUDIT_ACE_TYPE 0x00000002
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 [RFC3010] section 5.9.2: Version 4 Protocol [RFC3010] section 5.9.2:
skipping to change at page 22, line 36 skipping to change at page 21, line 27
ACE4_DELETE_CHILD 0x00000040 ACE4_DELETE_CHILD 0x00000040
ACE4_READ_ATTRIBUTES 0x00000080 ACE4_READ_ATTRIBUTES 0x00000080
ACE4_WRITE_ATTRIBUTES 0x00000100 ACE4_WRITE_ATTRIBUTES 0x00000100
ACE4_DELETE 0x00010000 ACE4_DELETE 0x00010000
ACE4_READ_ACL 0x00020000 ACE4_READ_ACL 0x00020000
ACE4_WRITE_ACL 0x00040000 ACE4_WRITE_ACL 0x00040000
ACE4_WRITE_OWNER 0x00080000 ACE4_WRITE_OWNER 0x00080000
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 7.5)
Also, as per '5.9.4 ACE who' [RFC3010] there are several identifiers Also, as per '5.9.4 ACE who' [RFC3010] there are several identifiers
that need to be understood universally. Some of these identifiers that need to be understood universally. Some of these identifiers
cannot be understood when an client access the server, but have cannot be understood when an client access the server, but have
meaning when a local process accesses the file. The ability to meaning when a local process accesses the file. The ability to
display and modify 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.
skipping to change at page 23, line 4 skipping to change at page 21, line 42
meaning when a local process accesses the file. The ability to meaning when a local process accesses the file. The ability to
display and modify 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).
SERVICE Access from a system service. SERVICE Access from a system service.
To avoid conflict, these special identifiers are distinguish by an To avoid conflict, these special identifiers are distinguish by an
appended "@". For example: ANONYMOUS@. appended "@". For example: ANONYMOUS@.
6.9 attrib-bits and attrib-bits-valid 7.9. attrib-bits and attrib-bits-valid
These fields, taken together, reflect various attributes of the file These fields, taken together, reflect various attributes of the file
or directory, on the server. or directory, on the server.
Bits not set in 'attrib-bits-valid' MUST be ignored in the 'attrib- Bits not set in 'attrib-bits-valid' MUST be ignored in the 'attrib-
bits' field. This allows both the server and the client to bits' field. This allows both the server and the client to
communicate only the bits it knows about without inadvertantly communicate only the bits it knows about without inadvertently
twiddling bits they don't understand. twiddling bits they don't understand.
The following attrib-bits are defined: The following attrib-bits are defined:
SSH_FILEXFER_ATTR_FLAGS_READONLY 0x00000001 SSH_FILEXFER_ATTR_FLAGS_READONLY 0x00000001
SSH_FILEXFER_ATTR_FLAGS_SYSTEM 0x00000002 SSH_FILEXFER_ATTR_FLAGS_SYSTEM 0x00000002
SSH_FILEXFER_ATTR_FLAGS_HIDDEN 0x00000004 SSH_FILEXFER_ATTR_FLAGS_HIDDEN 0x00000004
SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE 0x00000008 SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE 0x00000008
SSH_FILEXFER_ATTR_FLAGS_ARCHIVE 0x00000010 SSH_FILEXFER_ATTR_FLAGS_ARCHIVE 0x00000010
SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED 0x00000020 SSH_FILEXFER_ATTR_FLAGS_ENCRYPTED 0x00000020
skipping to change at page 23, line 48 skipping to change at page 22, line 37
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 the operating system. The file is part of the operating system.
SSH_FILEXFER_ATTR_FLAGS_HIDDEN SSH_FILEXFER_ATTR_FLAGS_HIDDEN
File SHOULD NOT be shown to user unless specifically requested. File SHOULD NOT be shown to user unless specifically requested.
For example, most UNIX systems SHOULD set this bit if the filename For example, most UNIX systems SHOULD set this bit if the filename
begins with a 'period'. This bit may be read-only (Section 4.5). begins with a 'period'. This bit may be read-only (Section 5.4).
Most UNIX systems will not allow this to be changed. Most UNIX systems will not allow this to be changed.
SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE
This attribute applies only to directories. This attribute is This attribute applies only to directories. This attribute is
always read-only, and cannot be modified. This attribute means always read-only, and cannot be modified. This attribute means
that files and directory names in this directory should be that files and directory names in this directory should be
compared without regard to case. compared without regard to case.
It is recommended that where possible, the server's filesystem be It is recommended that where possible, the server's filesystem be
allowed to do comparisons. For example, if a client wished to allowed to do comparisons. For example, if a client wished to
skipping to change at page 24, line 49 skipping to change at page 23, line 36
file, the blocks between the previous EOF marker and the 10 M file, the blocks between the previous EOF marker and the 10 M
offset would not consume physical disk space. offset would not consume physical disk space.
Some servers may store all files as sparse files, in which case Some servers may store all files as sparse files, in which case
this bit will be unconditionally set. Other servers may not have this bit will be unconditionally set. Other servers may not have
a mechanism for determining if the file is sparse, and so the file a mechanism for determining if the file is sparse, and so the file
MAY be stored sparse even if this flag is not set. MAY be stored sparse even if this flag is not set.
SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY
Opening the file without either the SSH_FXF_ACCESS_APPEND_DATA or Opening the file without either the SSH_FXF_ACCESS_APPEND_DATA or
the SSH_FXF_ACCESS_APPEND_DATA_ATOMIC flag (Section 7.1.1.3) MUST the SSH_FXF_ACCESS_APPEND_DATA_ATOMIC flag (Section 8.1.1.3) MUST
result in an SSH_FX_INVALID_PARAMETER error. result in an SSH_FX_INVALID_PARAMETER error.
SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE
The file cannot be deleted or renamed, no hard link can be created The file cannot be deleted or renamed, no hard link can be created
to this file, and no data can be written to the file. to this file, and no data can be written to the file.
This bit implies a stronger level of protection than This bit implies a stronger level of protection than
SSH_FILEXFER_ATTR_FLAGS_READONLY, the file permission mask or SSH_FILEXFER_ATTR_FLAGS_READONLY, the file permission mask or
ACLs. Typically even the superuser cannot write to immutable ACLs. Typically even the superuser cannot write to immutable
files, and only the superuser can set or remove the bit. files, and only the superuser can set or remove the bit.
skipping to change at page 25, line 24 skipping to change at page 24, line 15
SSH_FILEXFER_ATTR_FLAGS_SYNC SSH_FILEXFER_ATTR_FLAGS_SYNC
When the file is modified, the changes are written synchronously When the file is modified, the changes are written synchronously
to the disk. to the disk.
SSH_FILEXFER_ATTR_FLAGS_TRANSLATION_ERR SSH_FILEXFER_ATTR_FLAGS_TRANSLATION_ERR
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 7.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.
SSH_FILEXFER_ATTR_KNOWN_TEXT 0x00 SSH_FILEXFER_ATTR_KNOWN_TEXT 0x00
SSH_FILEXFER_ATTR_GUESSED_TEXT 0x01 SSH_FILEXFER_ATTR_GUESSED_TEXT 0x01
SSH_FILEXFER_ATTR_KNOWN_BINARY 0x02 SSH_FILEXFER_ATTR_KNOWN_BINARY 0x02
SSH_FILEXFER_ATTR_GUESSED_BINARY 0x03 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 heuristic 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.
SSH_FILEXFER_ATTR_KNOWN_BINARY SSH_FILEXFER_ATTR_KNOWN_BINARY
The server knows the file has binary content. The server knows the file has binary content.
SSH_FILEXFER_ATTR_GUESSED_BINARY SSH_FILEXFER_ATTR_GUESSED_BINARY
The server has applied a hueristic or other mechanism and believes The server has applied a heuristic or other mechanism and believes
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 either a setstat or a fsetstat This flag MUST NOT be present during either a setstat or a fsetstat
operation. operation.
6.11 mime-type 7.11. mime-type
The 'mime-type' field contains the mime-type [RFC1521] 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 7.12. link-count
This field contains the hard link count of the file. This attribute This field contains the hard link count of the file. This attribute
MUST NOT be present during a setstat operation. MUST NOT be present during a setstat operation.
6.13 untranslated-name 7.13. untranslated-name
This field contains the name before filename translation was attempt. This field contains the name before filename translation was attempt.
It MUST NOT be included unless the server also set the It MUST NOT be included unless the server also set the
SSH_FILEXFER_ATTR_FLAGS_TRANSLATION_ERR (Section 6.9) bit in the SSH_FILEXFER_ATTR_FLAGS_TRANSLATION_ERR (Section 7.9) bit in the
attrib-bits field. attrib-bits field.
6.14 Extended Attributes 7.14. Extended Attributes
The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension
mechanism for the attrib structure. If the flag is specified, then mechanism for the attrib structure. If the flag is specified, then
the 'extended_count' field is present. It specifies the number of the 'extended_count' field is present. It specifies the number of
'extension-pair' items that follow. Each of these items specifies an 'extension-pair' items that follow. Each of these items specifies an
extended attribute. Implementations MUST return SSH_FX_UNSUPPORTED extended attribute. Implementations MUST return SSH_FX_UNSUPPORTED
if there are any unrecognized extensions. Clients can avoid sending if there are any unrecognized extensions. Clients can avoid sending
unsupported extensions by examining the attrib-extension-names of the unsupported extensions by examining the attrib-extension-names of the
"supported2" extension attrib-extension-names (Section 4.5). "supported2" extension attrib-extension-names (Section 5.4).
Additional fields can be added to the attributes by either defining Additional fields can be added to the attributes by either defining
additional bits to the flags field to indicate their presence, or by additional bits to the flags field to indicate their presence, or by
defining extended attributes for them. The extended attributes defining extended attributes for them. The extended attributes
mechanism is recommended for most purposes; additional flags bits mechanism is recommended for most purposes; additional flags bits
should be defined only by an IETF standards action that also should be defined only by an IETF standards action that also
increments the protocol version number. The use of such new fields increments the protocol version number. The use of such new fields
MUST be negotiated by the version number in the protocol exchange. MUST be negotiated by the version number in the protocol exchange.
It is a protocol error if a packet with unsupported protocol bits is It is a protocol error if a packet with unsupported protocol bits is
received. received.
7. Requests From the Client to the Server 8. Requests From the Client to the Server
Requests from the client to the server represent the various file Requests from the client to the server represent the various file
system operations. system operations.
7.1 Opening and Closing Files and Directories 8.1. Opening and Closing Files and Directories
Many operations in the protocol operate on open files. The Many operations in the protocol operate on open files. The
SSH_FXP_OPEN and SSH_FXP_OPENDIR requests return a handle (which is SSH_FXP_OPEN and SSH_FXP_OPENDIR requests return a handle (which is
an opaque, variable-length string) which may be used to access the an opaque, variable-length string) which may be used to access the
file or directory later. The client MUST NOT send requests to the file or directory later. The client MUST NOT send requests to the
server with bogus or closed handles. However, the server MUST server with bogus or closed handles. However, the server MUST
perform adequate checks on the handle in order to avoid security perform adequate checks on the handle in order to avoid security
risks due to fabricated handles. risks due to fabricated handles.
This design allows either stateful and stateless server This design allows either stateful and stateless server
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 8.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.)
7.1.1.1 filename 8.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. If 'filename' is a directory file, the Names'' for more information. If 'filename' is a directory file, the
server MUST return an SSH_FX_FILE_IS_A_DIRECTORY error. server MUST return an SSH_FX_FILE_IS_A_DIRECTORY error.
7.1.1.2 desired-access 8.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 (Section 6.8). Note that again, the values from the ace-mask flags (Section 7.8). Note that again, the
meaning of these flags is given in [RFC3010]. meaning of these flags is given in [RFC3010].
The server MUST be prepared to translate the SFTP access flags into The server MUST be prepared to translate the SFTP access flags into
its local equivalents. If the server cannot grant the access its local equivalents. If the server cannot grant the access
desired, it MUST return SSH_FX_PERMISSION_DENIED. desired, it MUST return SSH_FX_PERMISSION_DENIED.
The server MAY open the file with greater access than requested if The server MAY open the file with greater access than requested if
the user has such access and the server implementation requires it. the user has such access and the server implementation requires it.
For example, a server that does not distinguish between For example, a server that does not distinguish between
READ_ATTRIBUTE and READ_DATA will have to request full 'read' access READ_ATTRIBUTE and READ_DATA will have to request full 'read' access
to the file when the client only requested READ_ATTRIBUTE, resulting to the file when the client only requested READ_ATTRIBUTE, resulting
in greater access than the client originaly requested. in greater access than the client originally requested.
In such cases, it is possible, and permissable in the protocol, that In such cases, it is possible, and permissible in the protocol, that
the client could open a file requesting some limited access, and then the client could open a file requesting some limited access, and then
access the file in a way not permitted by that limited access and the access the file in a way not permitted by that limited access and the
server would permit such action. However, the server MUST NOT ever server would permit such action. However, the server MUST NOT ever
grant access to the file that the client does not actually have the grant access to the file that the client does not actually have the
rights to. rights to.
7.1.1.3 flags 8.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
skipping to change at page 29, line 48 skipping to change at page 28, line 37
Data MUST be written atomically so that there is no chance that Data MUST be written atomically so that there is no chance that
multiple appenders can collide and result in data being lost. multiple appenders can collide and result in data being lost.
If both append flags are specified, the server SHOULD use atomic If both append flags are specified, the server SHOULD use atomic
append if it is available, but SHOULD use non-atomic appends append if it is available, but SHOULD use non-atomic appends
otherwise. The server SHOULD NOT fail the request in this case. otherwise. The server SHOULD NOT fail the request in this case.
SSH_FXF_ACCESS_TEXT_MODE SSH_FXF_ACCESS_TEXT_MODE
Indicates that the server should treat the file as text and Indicates that the server should treat the file as text and
convert it to the canonical newline convention in use. (See convert it to the canonical newline convention in use. (See
Determining Server Newline Convention. (Section 4.3) Determining Server Newline Convention. (Section 5.3)
When a file is opened with this flag, the offset field in the read When a file is opened with this flag, the offset field in the read
and write functions is ignored. and write functions is ignored.
Servers MUST process multiple, parallel reads and writes correctly Servers MUST process multiple, parallel reads and writes correctly
in this mode. Naturally, it is permissible for them to do this by in this mode. Naturally, it is permissible for them to do this by
serializing the requests. serializing the requests.
Clients SHOULD use the SSH_FXF_ACCESS_APPEND_DATA flag to append Clients SHOULD use the SSH_FXF_ACCESS_APPEND_DATA flag to append
data to a text file rather then using write with a calculated data to a text file rather then using write with a calculated
offset. offset.
skipping to change at page 31, line 6 skipping to change at page 29, line 39
with ACE4_READ_DATA access, and that no other handle will be with ACE4_READ_DATA access, and that no other handle will be
opened with ACE4_READ_DATA access until the client closes the opened with ACE4_READ_DATA access until the client closes the
handle. (This MUST apply both to other clients and to other handle. (This MUST apply both to other clients and to other
processes on the server.) processes on the server.)
If there is a conflicting lock the server MUST return If there is a conflicting lock the server MUST return
SSH_FX_LOCK_CONFLICT. If the server cannot make the locking SSH_FX_LOCK_CONFLICT. If the server cannot make the locking
guarantee, it MUST return SSH_FX_OP_UNSUPPORTED. guarantee, it MUST return SSH_FX_OP_UNSUPPORTED.
Other handles MAY be opened for ACE4_WRITE_DATA or any other Other handles MAY be opened for ACE4_WRITE_DATA or any other
combinatation of accesses, as long as ACE4_READ_DATA is not combination of accesses, as long as ACE4_READ_DATA is not included
included in the mask. in the mask.
SSH_FXF_ACCESS_BLOCK_WRITE SSH_FXF_ACCESS_BLOCK_WRITE
The server MUST guarantee that no other handle has been opened The server MUST guarantee that no other handle has been opened
with ACE4_WRITE_DATA or ACE4_APPEND_DATA access, and that no other with ACE4_WRITE_DATA or ACE4_APPEND_DATA access, and that no other
handle will be opened with ACE4_WRITE_DATA or ACE4_APPEND_DATA handle will be opened with ACE4_WRITE_DATA or ACE4_APPEND_DATA
access until the client closes the handle. (This MUST apply both access until the client closes the handle. (This MUST apply both
to other clients and to other processes on the server.) to other clients and to other processes on the server.)
If there is a conflicting lock the server MUST return If there is a conflicting lock the server MUST return
SSH_FX_LOCK_CONFLICT. If the server cannot make the locking SSH_FX_LOCK_CONFLICT. If the server cannot make the locking
guarantee, it MUST return SSH_FX_OP_UNSUPPORTED. guarantee, it MUST return SSH_FX_OP_UNSUPPORTED.
Other handles MAY be opened for ACE4_READ_DATA or any other Other handles MAY be opened for ACE4_READ_DATA or any other
combinatation of accesses, as long as neither ACE4_WRITE_DATA nor combination of accesses, as long as neither ACE4_WRITE_DATA nor
ACE4_APPEND_DATA are included in the mask. ACE4_APPEND_DATA are included in the mask.
SSH_FXF_ACCESS_BLOCK_DELETE SSH_FXF_ACCESS_BLOCK_DELETE
The server MUST guarantee that no other handle has been opened The server MUST guarantee that no other handle has been opened
with ACE4_DELETE access, opened with the with ACE4_DELETE access, opened with the
SSH_FXF_ACCESS_DELETE_ON_CLOSE flag set, and that no other handle SSH_FXF_ACCESS_DELETE_ON_CLOSE flag set, and that no other handle
will be opened with ACE4_DELETE access or with the will be opened with ACE4_DELETE access or with the
SSH_FXF_ACCESS_DELETE_ON_CLOSE flag set, and that the file itself SSH_FXF_ACCESS_DELETE_ON_CLOSE flag set, and that the file itself
is not deleted in any other way until the client closes the is not deleted in any other way until the client closes the
handle. handle.
skipping to change at page 32, line 47 skipping to change at page 31, line 34
O_CREAT O_CREAT
flags = SSH_FXF_OPEN_OR_CREATE flags = SSH_FXF_OPEN_OR_CREATE
O_TRUNC O_TRUNC
flags = SSH_FXF_TRUNCATE_EXISTING flags = SSH_FXF_TRUNCATE_EXISTING
O_TRUNC|O_CREATE O_TRUNC|O_CREATE
flags = SSH_FXF_CREATE_TRUNCATE flags = SSH_FXF_CREATE_TRUNCATE
7.1.2 Opening a Directory 8.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]
path path
The 'path' field is the path name of the directory to be listed The 'path' field is the path name of the directory to be listed
(without any trailing slash). See Section 'File Names' for more (without any trailing slash). See Section 'File Names' for more
information on file names. information on file names.
If 'path' does not refer to a directory, the server MUST return If 'path' does not refer to a directory, the server MUST return
SSH_FX_NOT_A_DIRECTORY. SSH_FX_NOT_A_DIRECTORY.
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 8.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
handle handle
'handle' is a handle previously returned in the response to 'handle' is a handle previously returned in the response to
SSH_FXP_OPEN or SSH_FXP_OPENDIR. The handle becomes invalid SSH_FXP_OPEN or SSH_FXP_OPENDIR. The handle becomes invalid
skipping to change at page 33, line 46 skipping to change at page 32, line 37
flushing cached writes, the close operation may fail. flushing cached writes, the close operation may fail.
Note that the handle is invalid regardless of the SSH_FXP_STATUS Note that the handle is invalid regardless of the SSH_FXP_STATUS
result. There is no way for the client to recover a handle that result. There is no way for the client to recover a handle that
fails to close. The client MUST release all resources associated fails to close. The client MUST release all resources associated
with the handle regardless of the status. The server SHOULD take with the handle regardless of the status. The server SHOULD take
whatever steps it can to recover from a close failure and to ensure whatever steps it can to recover from a close failure and to ensure
that all resources associated with the handle on the server are that all resources associated with the handle on the server are
correctly released. correctly released.
7.2 Reading and Writing 8.2. Reading and Writing
7.2.1 Reading Files 8.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
handle handle
'handle' is an open file handle returned by SSH_FXP_OPEN. If '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 'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST
return SSH_FX_INVALID_HANDLE. return SSH_FX_INVALID_HANDLE.
offset offset
The offset (in bytes) relative to the beginning of the file that The offset (in bytes) relative to the beginning of the file that
the read MUST start at. This field is ignored if the read MUST start at. This field is ignored if
SSH_FXF_ACCESS_TEXT_MODE was specified during the open. SSH_FXF_ACCESS_TEXT_MODE was specified during the open.
skipping to change at page 34, line 30 skipping to change at page 33, line 23
length length
'length' is the maximum number of bytes to read. 'length' is the maximum number of bytes to read.
The server MUST not respond with more data than is specified by The server MUST not respond with more data than is specified by
the 'length' parameter. However, the server MAY respond with less the 'length' parameter. However, the server MAY respond with less
data if EOF is reached, an error is encountered, or the servers data if EOF is reached, an error is encountered, or the servers
internal buffers can not handle such a large request. internal buffers can not handle such a large request.
If the server specified a non-zero 'max-read-size' in its If the server specified a non-zero 'max-read-size' in its
'supported2' (Section 4.5) extension, then failure to return 'supported2' (Section 5.4) extension, then failure to return
'length' bytes indicates that EOF or an error occured. 'length' bytes indicates that EOF or an error occurred.
7.2.2 Reading Directories 8.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
skipping to change at page 35, line 4 skipping to change at page 33, line 44
uint32 request-id uint32 request-id
string handle string handle
handle handle
'handle' is a handle returned by SSH_FXP_OPENDIR. If 'handle' is 'handle' is a handle returned by SSH_FXP_OPENDIR. If 'handle' is
an ordinary file handle returned by SSH_FXP_OPEN, the server MUST an ordinary file handle returned by SSH_FXP_OPEN, the server MUST
return SSH_FX_INVALID_HANDLE. 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 8.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
handle handle
skipping to change at page 35, line 43 skipping to change at page 34, line 37
end of the file; the semantics are to write the byte value 0x00 end of the file; the semantics are to write the byte value 0x00
from the end of the file to the specified offset and then the from the end of the file to the specified offset and then the
data. On most operating systems, such writes do not allocate disk data. On most operating systems, such writes do not allocate disk
space but instead create a sparse file. space but instead create a sparse file.
data data
The data to write to the file. 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 8.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]
filename filename
'filename' is the name of the file to be removed. See Section 'filename' is the name of the file to be removed. See Section
'File Names' for more information. 'File Names' for more information.
This request cannot be used to remove directories. The server This request cannot be used to remove directories. The server
MUST return SSH_FX_FILE_IS_A_DIRECTORY in this case. 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.
skipping to change at page 36, line 29 skipping to change at page 35, line 26
string oldpath [UTF-8] string oldpath [UTF-8]
string newpath [UTF-8] string newpath [UTF-8]
uint32 flags uint32 flags
where 'request-id' is the request identifier, 'oldpath' is the name where 'request-id' is the request identifier, 'oldpath' is the name
of an existing file or directory, and 'newpath' is the new name for of an existing file or directory, and 'newpath' is the new name for
the file or directory. the file or directory.
'flags' is 0 or a combination of: 'flags' is 0 or a combination of:
SSH_FXP_RENAME_OVERWRITE 0x00000001 SSH_FXF_RENAME_OVERWRITE 0x00000001
SSH_FXP_RENAME_ATOMIC 0x00000002 SSH_FXF_RENAME_ATOMIC 0x00000002
SSH_FXP_RENAME_NATIVE 0x00000004 SSH_FXF_RENAME_NATIVE 0x00000004
If flags does not include SSH_FXP_RENAME_OVERWRITE, and there already If flags does not include SSH_FXP_RENAME_OVERWRITE, and there already
exists a file with the name specified by newpath, the server MUST exists a file with the name specified by newpath, the server MUST
respond with SSH_FX_FILE_ALREADY_EXISTS. respond with SSH_FX_FILE_ALREADY_EXISTS.
If flags includes SSH_FXP_RENAME_ATOMIC, and the destination file If flags includes SSH_FXP_RENAME_ATOMIC, and the destination file
already exists, it is replaced in an atomic fashion. I.e., there is already exists, it is replaced in an atomic fashion. I.e., there is
no observable instant in time where the name does not refer to either no observable instant in time where the name does not refer to either
the old or the new file. SSH_FXP_RENAME_ATOMIC implies the old or the new file. SSH_FXP_RENAME_ATOMIC implies
SSH_FXP_RENAME_OVERWRITE. SSH_FXP_RENAME_OVERWRITE.
skipping to change at page 37, line 13 skipping to change at page 36, line 9
atomic rename even if it is not requested. atomic rename even if it is not requested.
If flags includes SSH_FXP_RENAME_NATIVE, the server is free to do the If flags includes SSH_FXP_RENAME_NATIVE, the server is free to do the
rename operation in whatever fashion it deems appropriate. Other rename operation in whatever fashion it deems appropriate. Other
flag values are considered hints as to desired behavior, but not flag values are considered hints as to desired behavior, but not
requirements. requirements.
The server will respond to this request with a SSH_FXP_STATUS The server will respond to this request with a SSH_FXP_STATUS
message. message.
7.4 Creating and Deleting Directories 8.4. Creating and Deleting Directories
New directories can be created using the SSH_FXP_MKDIR request. It New directories can be created using the SSH_FXP_MKDIR request. It
has the following format: has the following format:
byte SSH_FXP_MKDIR byte SSH_FXP_MKDIR
uint32 request-id uint32 request-id
string path [UTF-8] string path [UTF-8]
ATTRS attrs ATTRS attrs
where 'request-id' is the request identifier. where 'request-id' is the request identifier.
skipping to change at page 37, line 49 skipping to change at page 36, line 45
byte SSH_FXP_RMDIR byte SSH_FXP_RMDIR
uint32 request-id uint32 request-id
string path [UTF-8] string path [UTF-8]
where 'request-id' is the request identifier, and 'path' specifies where 'request-id' is the request identifier, and 'path' specifies
the directory to be removed. See Section ''File Names'' for more the directory to be removed. See Section ''File Names'' for more
information on file names. information on file names.
The server responds to this request with a SSH_FXP_STATUS message. The server responds to this request with a SSH_FXP_STATUS message.
7.5 Retrieving File Attributes 8.5. Retrieving File Attributes
Very often, file attributes are automatically returned by Very often, file attributes are automatically returned by
SSH_FXP_READDIR. However, sometimes there is need to specifically SSH_FXP_READDIR. However, sometimes there is need to specifically
retrieve the attributes for a named file. This can be done using the retrieve the attributes for a named file. This can be done using the
SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests. SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.
SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT
follows symbolic links on the server, whereas SSH_FXP_LSTAT does not follows symbolic links on the server, whereas SSH_FXP_LSTAT does not
follow symbolic links. Both have the same format: follow symbolic links. Both have the same format:
skipping to change at page 38, line 46 skipping to change at page 37, line 44
string handle string handle
uint32 flags uint32 flags
handle handle
'handle' is an open file handle from either SSH_FXP_OPEN or 'handle' is an open file handle from either SSH_FXP_OPEN or
SSH_FXP_OPENDIR. SSH_FXP_OPENDIR.
The server responds to this request with SSH_FXP_ATTRS or The server responds to this request with SSH_FXP_ATTRS or
SSH_FXP_STATUS. SSH_FXP_STATUS.
7.6 Setting File Attributes 8.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
skipping to change at page 39, line 38 skipping to change at page 38, line 34
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,
clients MUST be aware that this is possible. clients MUST be aware that this is possible.
7.7 Dealing with Links 8.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.
skipping to change at page 40, line 30 skipping to change at page 39, line 27
new-link-path will refer. new-link-path will refer.
sym-link sym-link
Specifies that the link should be a symbolic link, or a special Specifies that the link should be a symbolic link, or a special
file that redirects file system parsing to the resulting path. It file that redirects file system parsing to the resulting path. It
is generally possible to create symbolic links across device is generally possible to create symbolic links across device
boundaries; however, it is not required that a server support boundaries; however, it is not required that a server support
this. this.
If 'sym-link' is false, the link should be a hard link, or a If 'sym-link' is false, the link should be a hard link, or a
second directory entry refering to the same file or directory second directory entry referring to the same file or directory
object. It is generally not possible to create hard links across object. It is generally not possible to create hard links across
devices. devices.
The server shall respond with a SSH_FXP_STATUS. Clients should be The server shall respond with a SSH_FXP_STATUS. Clients should be
aware that some servers may return SSH_FX_OP_UNSUPPORTED for either aware that some servers may return SSH_FX_OP_UNSUPPORTED for either
the hard-link, sym-link, or both operations. the hard-link, sym-link, or both operations.
7.8 Byte-range locks 8.8. Byte-range locks
SSH_FXP_BLOCK creates a byte-range lock on the file specified by the SSH_FXP_BLOCK creates a byte-range lock on the file specified by the
handle. The lock can be either mandatory (meaning that the server handle. The lock can be either mandatory (meaning that the server
enforces that no other process or client can perform operations in enforces that no other process or client can perform operations in
violation of the lock) or advisory (meaning that no other process can violation of the lock) or advisory (meaning that no other process can
obtain a conflicting lock, but the server does not enforce that no obtain a conflicting lock, but the server does not enforce that no
operation violates the lock. operation violates the lock.
A server MAY implement an advisory lock in a mandatory fashion; in A server MAY implement an advisory lock in a mandatory fashion; in
other words, the server MAY enforce that no operation violates the other words, the server MAY enforce that no operation violates the
skipping to change at page 41, line 28 skipping to change at page 40, line 26
offset offset
Beginning of the byte-range to lock. Beginning of the byte-range to lock.
length length
Number of bytes in the range to lock. The special value 0 means Number of bytes in the range to lock. The special value 0 means
lock from 'offset' to the end of the file. lock from 'offset' to the end of the file.
uLockMask uLockMask
A bit mask of SSH_FXF_ACCESS_BLOCK_* values; the meanings are A bit mask of SSH_FXF_ACCESS_BLOCK_* values; the meanings are
described in Section 7.1.1.3. described in Section 8.1.1.3.
SSH_FXP_UNBLOCK removes a previously aquired byte-range lock on the SSH_FXP_UNBLOCK removes a previously acquired byte-range lock on the
specified handle. specified handle.
The result is a SSH_FXP_STATUS return. The result is a SSH_FXP_STATUS return.
byte SSH_FXP_UNBLOCK byte SSH_FXP_UNBLOCK
uint32 request-id uint32 request-id
string handle string handle
uint64 offset uint64 offset
uint64 length uint64 length
skipping to change at page 42, line 5 skipping to change at page 40, line 50
'handle' on which a SSH_FXP_BLOCK request has previously been 'handle' on which a SSH_FXP_BLOCK request has previously been
issued. issued.
offset offset
Beginning of the byte-range to lock. Beginning of the byte-range to lock.
length length
Number of bytes in the range to lock. The special value 0 means Number of bytes in the range to lock. The special value 0 means
lock from 'offset' to the end of the file. lock from 'offset' to the end of the file.
7.9 Canonicalizing the Server-Side Path Name 8.9. 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 original-path [UTF-8] string original-path [UTF-8]
skipping to change at page 42, line 46 skipping to change at page 41, line 42
form. For example, symlinks may not be followed in this case. form. For example, symlinks may not be followed in this case.
The server MAY fail the request if the path is not syntactically The server MAY fail the request if the path is not syntactically
valid, or for other reasons. valid, or for other reasons.
If SSH_FXP_REALPATH_STAT_IF is specified, the server MUST stat the 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 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 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 server MUST NOT fail the request. If the stat failed, the file
type will be SSH_FILEXFER_TYPE_UNKNOWN. If the client needs to type will be SSH_FILEXFER_TYPE_UNKNOWN. If the client needs to
distinguish between files that are actually distinguish between files that are actually
SSH_FILEXFER_TYPE_UNKNOWN and paths that don't exist, it will SSH_FILEXFER_TYPE_UNKNOWN and paths that don't exist, it will have
have to issue a seperate stat command in this case. to issue a separate stat command in this case.
If SSH_FXP_REALPATH_STAT_ALWAYS is specified the server MUST stat If SSH_FXP_REALPATH_STAT_ALWAYS is specified the server MUST stat
the path. If the stat operation fails, the server MUST fail the the path. If the stat operation fails, the server MUST fail the
request. request.
compose-path compose-path
A path which the client wishs the server to compose with the A path which the client wishes the server to compose with the
original path to form the new path. This field is optional, and 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 if it is not present in the packet, it is assumed to be a zero
length string. length string.
The client may specify multiple 'compose-path' elements, in which The client may specify multiple 'compose-path' elements, in which
case the server should build the resultant path up by applying case the server should build the resultant path up by applying
each compose path to the accumulated result until all 'compose- each compose path to the accumulated result until all 'compose-
path' elements have been applied. path' elements have been applied.
The server MUST take the 'original-path' and apply the 'compose-path' The server MUST take the 'original-path' and apply the 'compose-path'
as a modification to it. 'compose-path' MAY be relative to 'original- 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 path' or may be an absolute path, in which case 'original-path' will
be discarded. The 'compose-path' MAY be zero length. be discarded. The 'compose-path' MAY be zero length.
The server will respond with a SSH_FXP_NAME packet containing the The server will respond with a SSH_FXP_NAME packet containing the
canonical form of the composite path. If SSH_FXP_REALPATH_NO_CHECK canonical form of the composite path. If SSH_FXP_REALPATH_NO_CHECK
is specified, the attributes are dummy values. is specified, the attributes are dummy values.
7.9.1 Best Practice for Dealing with Paths 8.9.1. Best Practice for Dealing with Paths
BEGIN: RFCEDITOR REMOVE BEFORE PUBLISHING BEGIN: RFCEDITOR REMOVE BEFORE PUBLISHING
Previous to this version, clients typically composed new paths Previous to this version, clients typically composed new paths
themselves and then called both realpath and stat on the resulting themselves and then called both realpath and stat on the resulting
path to get its canonical name and see if it really existed and was a path to get its canonical name and see if it really existed and was a
directory. directory.
This required clients to assume certain things about how a relative This required clients to assume certain things about how a relative
vs. realpath looked. The new realpath allows clients to no longer vs. realpath looked. The new realpath allows clients to no longer
skipping to change at page 44, line 19 skipping to change at page 43, line 14
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
REALPATH("c:/x/y/z", "..", SSH_FXP_REALPATH_STAT_ALWAYS) REALPATH("c:/x/y/z", "..", SSH_FXP_REALPATH_STAT_ALWAYS)
As a second example, if the client wishes transfer local file "a" to As a second example, if the client wishes transfer local file "a" to
remote file "/b/d/e", 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 current directory, the client SHOULD send canonical path of the current directory, the client SHOULD send
REALPATH("dka100:/x/y/z", "/b/d/e", SSH_FXP_REALPATH_STAT_IF). This 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 call will determine the correct path to use for the open request and
whether the /b/d/e represents a directory. whether the /b/d/e represents a directory.
8. Responses from the Server to the Client 9. 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
response packet contains a request identifier which can be used to response packet contains a request identifier which can be used to
match each response with the corresponding request. Note that it is match each response with the corresponding request. Note that it is
legal to have several requests outstanding simultaneously, and the legal to have several requests outstanding simultaneously, and the
server is allowed to send responses to them in a different order from server is allowed to send responses to them in a different order from
the order in which the requests were sent (the result of their the order in which the requests were sent (the result of their
execution, however, is guaranteed to be as if they had been processed execution, however, is guaranteed to be as if they had been processed
one at a time in the order in which the requests were sent). one at a time in the order in which the requests were sent).
Response packets are of the same general format as request packets. Response packets are of the same general format as request packets.
Each response packet begins with the request identifier. Each response packet begins with the request identifier.
8.1 Status Response 9.1. Status Response
The format of the data portion of the SSH_FXP_STATUS response is as The format of the data portion of the SSH_FXP_STATUS response is as
follows: follows:
byte SSH_FXP_STATUS byte SSH_FXP_STATUS
uint32 request-id uint32 request-id
uint32 error/status code uint32 error/status code
string error message (ISO-10646 UTF-8 [RFC-2279]) string error message (ISO-10646 UTF-8 [RFC-2279])
string language tag (as defined in [RFC-1766]) string language tag (as defined in [RFC-1766])
error-specific data error-specific data
skipping to change at page 45, line 4 skipping to change at page 43, line 45
The format of the data portion of the SSH_FXP_STATUS response is as The format of the data portion of the SSH_FXP_STATUS response is as
follows: follows:
byte SSH_FXP_STATUS byte SSH_FXP_STATUS
uint32 request-id uint32 request-id
uint32 error/status code uint32 error/status code
string error message (ISO-10646 UTF-8 [RFC-2279]) string error message (ISO-10646 UTF-8 [RFC-2279])
string language tag (as defined in [RFC-1766]) string language tag (as defined in [RFC-1766])
error-specific data error-specific data
request-id request-id
The 'request-id' specified by the client in the request the server The 'request-id' specified by the client in the request the server
is responding to. is responding to.
error/status code error/status code
Machine readable status code indicating the result of the request. Machine readable status code indicating the result of the request.
Error code values are defined below. The value SSH_FX_OK Error code values are defined below. The value SSH_FX_OK
indicates success, and all other values indicate failure. indicates success, and all other values indicate failure.
Implementations MUST be prepared to receive unexpected error codes
and handle them sensibly (such as by treating them as equivalent
to SSH_FX_FAILURE). Future protocol revisions will add additional
error codes without changing the version number.
error message error message
Human readable description of the error. Human readable description of the error.
language tag language tag
'language tag' specifies the language the error is in. 'language tag' specifies 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 error- information about the error. For error codes that send error-
specific data, the format of the data is defined below. specific data, the format of the data is defined below.
skipping to change at page 46, line 34 skipping to change at page 45, line 34
SSH_FX_NOT_A_DIRECTORY 19 SSH_FX_NOT_A_DIRECTORY 19
SSH_FX_INVALID_FILENAME 20 SSH_FX_INVALID_FILENAME 20
SSH_FX_LINK_LOOP 21 SSH_FX_LINK_LOOP 21
SSH_FX_CANNOT_DELETE 22 SSH_FX_CANNOT_DELETE 22
SSH_FX_INVALID_PARAMETER 23 SSH_FX_INVALID_PARAMETER 23
SSH_FX_FILE_IS_A_DIRECTORY 24 SSH_FX_FILE_IS_A_DIRECTORY 24
SSH_FX_BYTE_RANGE_LOCK_CONFLICT 25 SSH_FX_BYTE_RANGE_LOCK_CONFLICT 25
SSH_FX_BYTE_RANGE_LOCK_REFUSED 26 SSH_FX_BYTE_RANGE_LOCK_REFUSED 26
SSH_FX_DELETE_PENDING 27 SSH_FX_DELETE_PENDING 27
SSH_FX_FILE_CORRUPT 28 SSH_FX_FILE_CORRUPT 28
SSH_FX_OWNER_INVALID 29
SSH_FX_GROUP_INVALID 30
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.
SSH_FX_PERMISSION_DENIED SSH_FX_PERMISSION_DENIED
The user does not have sufficient permissions to perform the The user does not have sufficient permissions to perform the
operation. operation.
SSH_FX_FAILURE SSH_FX_FAILURE
An error occured, but no specific error code exists to describe An error occurred, but no specific error code exists to describe
the failure. the failure.
This error message SHOULD always have meaningful text in the the This error message SHOULD always have meaningful text in the the
'error message' field. 'error message' field.
SSH_FX_BAD_MESSAGE SSH_FX_BAD_MESSAGE
A badly formatted packet or other SFTP protocol incompatibility A badly formatted packet or other SFTP protocol incompatibility
was detected. was detected.
SSH_FX_NO_CONNECTION SSH_FX_NO_CONNECTION
skipping to change at page 48, line 48 skipping to change at page 47, line 48
SSH_FX_CANNOT_DELETE SSH_FX_CANNOT_DELETE
The file cannot be deleted. One possible reason is that the The file cannot be deleted. One possible reason is that the
advisory READONLY attribute-bit is set. advisory READONLY attribute-bit is set.
SSH_FX_INVALID_PARAMETER SSH_FX_INVALID_PARAMETER
On of the parameters was out of range, or the parameters specified On of the parameters was out of range, or the parameters specified
cannot be used together. cannot be used together.
SSH_FX_FILE_IS_A_DIRECTORY SSH_FX_FILE_IS_A_DIRECTORY
The specifed file was a directory in a context where a directory The specified file was a directory in a context where a directory
cannot be used. cannot be used.
SSH_FX_BYTE_RANGE_LOCK_CONFLICT SSH_FX_BYTE_RANGE_LOCK_CONFLICT
A read or write operation failed because another process's A read or write operation failed because another process's
mandatory byte-range lock overlaps with the request. mandatory byte-range lock overlaps with the request.
SSH_FX_BYTE_RANGE_LOCK_REFUSED SSH_FX_BYTE_RANGE_LOCK_REFUSED
A request for a byte range lock was refused. A request for a byte range lock was refused.
SSH_FX_DELETE_PENDING SSH_FX_DELETE_PENDING
An operation was attempted on a file for which a delete operation An operation was attempted on a file for which a delete operation
is pending. is pending.
SSH_FX_FILE_CORRUPT SSH_FX_FILE_CORRUPT
The file is corrupt; an filesystem integrity check should be run. The file is corrupt; an filesystem integrity check should be run.
8.2 Handle Response SSH_FX_OWNER_INVALID
The principal specified can not be assigned as an owner of a file.
SSH_FX_GROUP_INVALID
The principal specified can not be assigned as the primary group
of a file.
9.2. Handle Response
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
'handle' 'handle'
An arbitrary string that identifies an open file or directory on An arbitrary string that identifies an open file or directory on
the server. The handle is opaque to the client; the client MUST the server. The handle is opaque to the client; the client MUST
NOT attempt to interpret or modify it in any way. The length of NOT attempt to interpret or modify it in any way. The length of
the handle string MUST NOT exceed 256 data bytes. the handle string MUST NOT exceed 256 data bytes.
8.3 Data Response 9.3. Data Response
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] bool end-of-file [optional]
data data
'data' is an arbitrary byte string containing the requested 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 The data string may be at most the number of bytes requested in a
SSH_FXP_READ request, but may also be shorter. (See SSH_FXP_READ request, but may also be shorter. (See
Section 7.2.1.) Section 8.2.1.)
end-of-file end-of-file
This field is optional. If it is present in the packet, it MUST This field is optional. If it is present in the packet, it MUST
be true, and it indicates that EOF was reached during this read. be true, and it indicates that EOF was reached during this read.
This can help the client avoid a round trip to determine whether a This can help the client avoid a round trip to determine whether a
short read was normal (due to EOF) or some other problem (limited short read was normal (due to EOF) or some other problem (limited
server buffer for example.) server buffer for example.)
8.4 Name Response 9.4. Name Response
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] bool end-of-list [optional]
skipping to change at page 50, line 42 skipping to change at page 50, line 5
attrs attrs
The attributes of the file as described in Section ''File The attributes of the file as described in Section ''File
Attributes''. Attributes''.
end-of-list end-of-list
This field is optional. If present in the packet, it MUST be This field is optional. If present in the packet, it MUST be
true, and indicates that there are no more entries to be read. 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 This can save the client a round trip to determine if there are
more entries to be read. more entries to be read.
8.5 Attrs Response 9.5. Attrs Response
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
attrs attrs
The returned file attributes as described in Section ''File The returned file attributes as described in Section ''File
Attributes''. Attributes''.
9. Extensions 10. Extensions
The SSH_FXP_EXTENDED request provides a generic extension mechanism The SSH_FXP_EXTENDED request provides a generic extension mechanism
for adding additional commands. for adding additional commands.
byte SSH_FXP_EXTENDED byte SSH_FXP_EXTENDED
uint32 request-id uint32 request-id
string extended-request string extended-request
... any request-specific data ... ... any request-specific data ...
request-id request-id
skipping to change at page 52, line 14 skipping to change at page 51, line 22
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 addition to any other data. values to use, in addition 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 File Hashing 11. Implementation Considerations
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
thereof) that it already has matches what is on the server.
byte SSH_FXP_EXTENDED
uint32 request-id
string "md5-hash" / "md5-hash-handle"
string filename [UTF-8] / file-handle
uint64 start-offset
uint64 length
string quick-check-hash
filename
Used if "md5-hash" is specified; indicates the name of the file to
use. The hash will be of the file contents as it would appear on
the wire if the file were opened with no special flags.
file-handle
Used if "md5-hash-handle" is specified; specifies a file handle to
read the data from. The handle MUST be a file handle, and
ACE4_READ_DATA MUST have been included in the desired-access when
the file was opened.
If this file handle was opened in SSH_FXF_ACCESS_TEXT_MODE mode,
the md5-hash must be made of the data as it would be sent on the
wire.
start-offset
The starting offset of the data to hash.
length
The length of data to include in the hash. If both start-offset
and length are zero, the entire file should be included.
quick-check-hash
The hash over the first 2048 bytes of the data range as the client
knows it, or the entire range, if it is less than 2048 bytes.
This allows the server to quickly check if it is worth the
resources to hash a big file.
If this is a zero length string, the client does not have the
data, and is requesting the hash for reasons other than comparing
with a local file. The server MAY return SSH_FX_OP_UNSUPPORTED in
this case.
The response is either a SSH_FXP_STATUS packet, indicating an error,
or the following extended reply packet:
byte SSH_FXP_EXTENDED_REPLY
uint32 request-id
string "md5-hash"
string hash
If 'hash' is zero length, then the 'quick-check-hash' did not match,
and no hash operation was preformed. Otherwise, 'hash' contains the
hash of the entire data range (including the first 2048 bytes that
were included in the 'quick-check-hash'.)
9.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-handle" / "check-file-name"
string handle / name
string hash-algorithm-list
uint64 start-offset
uint64 length
uint32 block-size
handle
For "check-file-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 was not included when the file was opened, the
server MUST return STATUS_PERMISSION_DENIED.
If this file handle was opened in SSH_FXF_ACCESS_TEXT_MODE mode,
the check must be performed on the data as it would be sent on the
wire.
name
For "check-file-name", 'name' is the path to the file to check.
If 'check-file-name' is a directory, SSH_FX_FILE_IS_A_DIRECTORY
SHOULD be returned. If 'check-file-name' refers to a
SSH_FILEXFER_TYPE_SYMLINK, the target should be opened. The
results are undefined file types other than
SSH_FILEXFER_TYPE_REGULAR.
The file MUST be opened without the SSH_FXF_ACCESS_TEXT_MODE
access flag (in binary mode.)
hash-algorithm-list
A comma separated list of hash algorithms the client is willing to
accept for this operation. The server MUST pick the first hash on
the list that it supports.
Currently defined 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]. [ISO.3309.1991]
describes crc32, 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 every 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 computed over only the
remainder of the range instead of a full block.
9.2 Querying Available Space
The following extension provides a way to discover the available
space for an arbitrary path.
byte SSH_FXP_EXTENDED
uint32 request-id
string "space-available"
string path [UTF-8]
path
'path' for which the available space should be reported. This
'path' is not required to be the mount point path, but MAY be a
directory or file contained within the mount.
The reply to the request is as follows:
byte SSH_FXP_EXTENDED_REPLY
uint32 request-id
uint64 bytes-on-device
uint64 unused-bytes-on-device
uint64 bytes-available-to-user
uint64 unused-bytes-available-to-user
uint32 bytes-per-allocation-unit
bytes-on-device
The total number of bytes on the device which stores 'path', both
used and unused, or 0 if unknown.
unused-bytes-on-device
The total number of unused bytes available on the device which
stores 'path', or 0 if unknown.
bytes-available-to-user
The total number of bytes, both used and unused, available to the
authenticated user on the device which stores 'path', or 0 if
unknown.
unused-bytes-available-to-user
The total number of unused bytes available to the authenticated
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
blocks, 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, suitable
for use in operations such as REALPATH or OPENDIR.
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
when the data size matches the channel's max packet, and the channel when the data size matches the channel's max packet, and the channel
window is a multiple of the channel packet size. window is a multiple of the channel packet size.
Implementations MUST be aware that requests do not have to be Implementations MUST be aware that requests do not have to be
satisfied in the order issued. (See Request Synchronization and satisfied in the order issued. (See Request Synchronization and
Reordering (Section 3.1).) Reordering (Section 4.1).)
Implementations MUST also be aware that read requests may not return Implementations MUST also be aware that read requests may not return
all the requested data, even if the data is available. all the requested data, even if the data is available.
11. Security Considerations 12. Security Considerations
It is assumed that both ends of the connection have been It is assumed that both ends of the connection have been
authenticated and that the connection has privacy and integrity authenticated and that the connection has privacy and integrity
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 (constrained only by the server implementation). It is the server (constrained only by the server implementation). It is the
skipping to change at page 58, line 36 skipping to change at page 52, line 19
particular user (the user being authenticated externally to this particular user (the user being authenticated externally to this
protocol, typically using [I-D.ietf-secsh-userauth]. 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 'file-share' session. For example, the 'file- the context of a given 'file-share' session. For example, the 'file-
share' server daemon may have files which it has opened for its own share' server daemon may have files which it has opened for its own
purposes, and the client must not be able to access these files by purposes, and the client must not be able to access these files by
specifying an arbitrary file handle string. 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 7.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
protocol. Servers should exercise caution when granting access to protocol. Servers should exercise caution when granting access to
such resources. In addition to the dangers inherent in allowing such resources. In addition to the dangers inherent in allowing
skipping to change at page 59, line 22 skipping to change at page 53, line 5
cannot be used to bypass access checks or controls. cannot be used to bypass access checks or controls.
If the server implementation limits access to certain parts of the If the server implementation limits access to certain parts of the
file system, extra care must be taken in parsing file names which file system, extra care must be taken in parsing file names which
contain the '..' path element, and when following symbolic links, contain the '..' path element, and when following symbolic links,
shortcuts, or other filesystem objects which might transpose the path shortcuts, or other filesystem objects which might transpose the path
to refer to an object outside of the restricted area. There have to refer to an object outside of the restricted area. There have
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 13. Changes from Previous Protocol Versions
The SSH File Transfer Protocol has changed over time, before its
standardization. The following is a description of the incompatible
changes between different versions.
12.1 Changes Between Versions 6 and 5
o Add ability to negotiate version when client supports discontigous
ranges of protocol version.
o Add 'filename-charset' and the 'filename-translation-control'
extensions to allow better support of servers that can't reliably
translate to UTF-8.
o Add DIR_NOT_EMPTY, NOT_A_DIRECTORY, INVALID_FILENAME LINK_LOOP,
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 NOFOLLOW and DELETE_ON_CLOSE flag to open flags.
o Added allocation-size, text-hint, link-count, mime-type, and
untranslated-name fields to attrib structure. Add
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.
o Change "supported" extension to "supported2", remove desired-
access-bits, seperate attrib extension from SSH_FXP_EXTENDED
extensions.
o Add "vendor-id" extension.
o Add ctime and attrib-bits-valid to attrib structure.
o Unrecognized attrib extensions cause failure rather than ignored.
o Optional 'end of data' flags on data and names responses.
o Add valid-access-mask back into supported2
o Add acl-present flag to acl.
12.2 Changes Between Versions 5 and 4
Many of the changes between version 5 and version 4 are to better
support the changes in version 4, and to better specify error
conditions.
o Add "supported" extension to communicate features supported.
o Clarify error handling when client requests unsupported feature.
(For example, attempts to write an unsupported attribute.)
o Add attrib-bits field to the attribute structure, which specifies
a number of boolean attributes related to files and directories,
including advisory read-only and case-sensitivity bits.
o Clarify the actual bit values to be used for the permissions field
(since POSIX doesn't define values) and correct the value of
ATTR_PERMISSIONS flag.
o Some reordering of sections to attempt to get a better grouping of
related functionality.
o Open request explicitly specifies the access desired for the file.
o Add support for explicitly requesting file locking.
o Add support for better control of the rename operation.
o Add SSH_FX_NO_SPACE_ON_FILESYSTEM, SSH_FX_QUOTA_EXCEEDED, and
SSH_FX_UNKNOWN_PRINCIPLE error codes.
o Add support for error specific data. This is used by a new
SSH_FX_UNKNOWN_PRINCIPLE error to communicate which principles are
unknown.
o Add support for retrieving md5-hash of file contents.
o Update security section.
12.3 Changes Between Versions 4 and 3
Many of the changes between version 4 and version 3 are to the
attribute structure to make it more flexible for non-unix platforms.
o Clarify the use of stderr by the server.
o Clarify handling of very large read requests by the server.
o Make all filenames UTF-8.
o Added 'newline' extension.
o Made time fields 64 bit, and optionally have nanosecond
resolution.
o Made file attribute owner and group strings so they can actually
be used on disparate systems.
o Added createtime field, and added separate flags for atime,
createtime, and mtime so they can be set separately.
o Split the file type out of the permissions field and into its own
field (which is always present.)
o Added acl attribute.
o Added SSH_FXF_TEXT file open flag.
o Added flags field to the get stat commands so that the client can
specifically request information the server might not normally
included for performance reasons.
o Removed the long filename from the names structure-- it can now be
built from information available in the attrs structure.
o Added reserved range of packet numbers for extensions.
o Added several additional error codes.
12.4 Changes Between Versions 3 and 2
o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added.
o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were
added.
o The SSH_FXP_STATUS message was changed to include fields 'error
message' and 'language tag'.
12.5 Changes Between Versions 2 and 1
o The SSH_FXP_RENAME message was added.
12.6 Changes Between Versions 1 and 0 RFC EDITOR: PLEASE REMOVE ENTIRE SECTION BEFORE PUBLISHING
o Implementation changes, no actual protocol changes. Please refer to the following web page for pervious versions of the
protocol:
13. References http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/
13.1 Normative References RFC EDITOR: END PLEASE REMOVE ENTIRE SECTION BEFORE PUBLISHING
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 14. References
April 1992.
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 14.1. Normative References
Authentication Service (V5)", RFC 1510, September 1993.
[RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "NFS version 4 Beame, C., Eisler, M., and D. Noveck, "NFS version 4
Protocol", RFC 3010, December 2000. Protocol", RFC 3010, December 2000.
[I-D.ietf-secsh-architecture] [I-D.ietf-secsh-architecture]
Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-22 (work in progress), draft-ietf-secsh-architecture-22 (work in progress),
March 2005. March 2005.
skipping to change at page 62, line 38 skipping to change at page 53, line 45
Lonvick, C. and T. Ylonen, "SSH Connection Protocol", Lonvick, C. and T. Ylonen, "SSH Connection Protocol",
draft-ietf-secsh-connect-25 (work in progress), draft-ietf-secsh-connect-25 (work in progress),
March 2005. March 2005.
[IEEE.1003-1.1996] [IEEE.1003-1.1996]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Information Technology - Portable Operating System "Information Technology - Portable Operating System
Interface (POSIX) - Part 1: System Application Program Interface (POSIX) - Part 1: System Application Program
Interface (API) [C Language]", IEEE Standard 1003.2, 1996. Interface (API) [C Language]", IEEE Standard 1003.2, 1996.
[FIPS-180-2] 14.2. Informative References
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.
13.2 Informative References
[RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", Describing the Format of Internet Message Bodies",
RFC 1521, September 1993. RFC 1521, September 1993.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[I-D.ietf-secsh-userauth] [I-D.ietf-secsh-userauth]
Lonvick, C. and T. Ylonen, "SSH Authentication Protocol", Lonvick, C. and T. Ylonen, "SSH Authentication Protocol",
draft-ietf-secsh-userauth-27 (work in progress), draft-ietf-secsh-userauth-27 (work in progress),
March 2005. March 2005.
Trademark notice
"ssh" is a registered trademark in the United States and/or other
countries.
Authors' Addresses 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 Oskari Saarenmaa
F-Secure F-Secure
Tammasaarenkatu 7 Tammasaarenkatu 7
Helsinki 00180 Helsinki 00180
FI FI
Email: oskari.saarenmaa@f-secure.com 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
 End of changes. 135 change blocks. 
655 lines changed or deleted 221 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/