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