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/ |