[要約] RFC 8276は、NFSv4におけるファイルシステムの拡張属性に関する仕様です。その目的は、NFSv4プロトコルで拡張属性をサポートするための標準化と一貫性の確保です。
Internet Engineering Task Force (IETF) M. Naik
Request for Comments: 8276 Nutanix
Category: Standards Track M. Eshel
ISSN: 2070-1721 IBM Almaden
December 2017
File System Extended Attributes in NFSv4
NFSv4のファイルシステム拡張属性
Abstract
概要
This document describes an optional feature extending the NFSv4 protocol. This feature allows extended attributes (hereinafter also referred to as xattrs) to be interrogated and manipulated using NFSv4 clients. Xattrs are provided by a file system to associate opaque metadata, not interpreted by the file system, with files and directories. Such support is present in many modern local file systems. New file attributes are provided to allow clients to query the server for xattr support, with that support consisting of new operations to get and set xattrs on file system objects.
このドキュメントでは、NFSv4プロトコルを拡張するオプション機能について説明します。この機能により、NFSv4クライアントを使用して、拡張属性（以下、xattrsとも呼ばれる）を調べて操作することができます。 Xattrsは、ファイルシステムによって提供され、ファイルシステムによって解釈されない不透明なメタデータをファイルおよびディレクトリに関連付けるために提供されます。このようなサポートは、現在の多くのローカルファイルシステムに存在しています。クライアントがサーバーにxattrサポートを照会できるように、新しいファイル属性が提供されています。このサポートは、ファイルシステムオブジェクトのxattrsを取得および設定するための新しい操作で構成されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8276.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8276で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Uses of Extended Attributes . . . . . . . . . . . . . . . . . 5
3. Functional Gaps Due to Lack of NFSv4 Extended Attribute
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. File System Support for Extended Attributes . . . . . . . . . 6
5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Relationship with Named Attributes . . . . . . . . . . . . . 7
7. XDR Description . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Code Components Licensing Notice . . . . . . . . . . . . 9
7.2. XDR for Xattr Extension . . . . . . . . . . . . . . . . . 11
8. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 11
8.1. New Definitions . . . . . . . . . . . . . . . . . . . . . 11
8.2. New Attribute . . . . . . . . . . . . . . . . . . . . . . 12
8.2.1. xattr_support . . . . . . . . . . . . . . . . . . . . 12
8.3. New Error Definitions . . . . . . . . . . . . . . . . . . 12
8.3.1. NFS4ERR_NOXATTR (Error Code 10095) . . . . . . . . . 12
8.3.2. NFS4ERR_XATTR2BIG (Error Code 10096) . . . . . . . . 13
8.4. New Operations . . . . . . . . . . . . . . . . . . . . . 13
8.4.1. GETXATTR - Get an Extended Attribute of a File . . . 14
8.4.2. SETXATTR - Set an Extended Attribute of a File . . . 15
8.4.3. LISTXATTRS - List Extended Attributes of a File . . . 17
8.4.4. REMOVEXATTR - Remove an Extended Attribute of a File 18
8.4.5. Valid Errors . . . . . . . . . . . . . . . . . . . . 19
8.5. Modifications to Existing Operations . . . . . . . . . . 21
8.6. Numeric Values Assigned to Protocol Extensions . . . . . 22
8.7. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.8. Xattrs and File Locking . . . . . . . . . . . . . . . . . 25
8.9. pNFS Considerations . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Extended attributes, also called xattrs, are a means to associate opaque metadata with file system objects, organized as key/value pairs. They are especially useful when they add information that is not, or cannot be, present in the associated object itself. User-space applications can arbitrarily create, interrogate, and modify the key/value pairs.
xattrsとも呼ばれる拡張属性は、不透明なメタデータをファイルシステムオブジェクトに関連付け、キーと値のペアとして編成する手段です。それらは、関連付けられたオブジェクト自体に存在しない、または存在できない情報を追加するときに特に役立ちます。ユーザー空間アプリケーションは、キー/値のペアを任意に作成、問い合わせ、および変更できます。
Extended attributes are file system agnostic; applications use an interface not specific to any file system to manipulate them. Applications are not concerned about how the key/value pairs are stored internally within the underlying file system. All major operating systems provide facilities to access and modify extended attributes. Many user-space tools allow xattrs to be included together with regular attributes that need to be preserved when objects are updated, moved, or copied.
拡張属性はファイルシステムに依存しません。アプリケーションは、ファイルシステムに固有ではないインターフェイスを使用して操作します。アプリケーションは、基になるファイルシステム内でキー/値のペアが内部的にどのように格納されるかを気にしません。すべての主要なオペレーティングシステムは、拡張属性にアクセスして変更する機能を提供します。多くのユーザー空間ツールでは、オブジェクトが更新、移動、またはコピーされたときに保持する必要がある通常の属性とともにxattrsを含めることができます。
Extended attributes have not previously been included within the NFSv4 specification. Some issues that need to be addressed in order to be included are that, as with named attributes, some aspects of the handling of xattrs are not precisely defined and xattrs are not formally documented by any standard such as POSIX [POSIX]. Nevertheless, it appears that xattrs are widely deployed, and their support in modern disk-based file systems is nearly universal.
拡張属性は、以前はNFSv4仕様に含まれていませんでした。含まれるために対処する必要があるいくつかの問題は、名前付き属性と同様に、xattrsの処理の一部の側面が正確に定義されておらず、xattrsがPOSIX [POSIX]などの標準によって正式に文書化されていないことです。それにもかかわらず、xattrsは広く展開されており、最近のディスクベースのファイルシステムでのxattrsのサポートはほぼ普遍的です。
There is no current specification of how xattrs could be mapped to any existing file attributes defined in the NFSv4 protocol [RFC5661] [RFC7530] [RFC7862]. As a result, most NFSv4 client implementations ignore application-specified xattrs. This state of affairs results in data loss if one copies, over the NFSv4 protocol, a file with xattrs from one file system to another that also supports xattrs.
NFSv4プロトコル[RFC5661] [RFC7530] [RFC7862]で定義されている既存のファイル属性にxattrsをどのようにマッピングできるかについての現在の仕様はありません。その結果、ほとんどのNFSv4クライアント実装は、アプリケーション指定のxattrsを無視します。この状況では、NFSv4プロトコルを介して、あるファイルシステムからxattrsをサポートする別のファイルシステムにxattrsを含むファイルをコピーすると、データが失われます。
There is thus a need to provide a means by which such data loss can be avoided. This will involve exposing xattrs within the NFSv4 protocol, despite the lack of completely compatible file system implementations.
したがって、そのようなデータ損失を回避できる手段を提供する必要がある。これには、完全に互換性のあるファイルシステムの実装がないにもかかわらず、NFSv4プロトコル内でxattrsを公開することが含まれます。
This document discusses (in Section 5) the reasons that NFSv4-named attributes, as currently standardized in [RFC5661], are unsuitable for representing xattrs. Instead, it describes a separate protocol mechanism to support xattrs. As a consequence, xattrs and named attributes will both be OPTIONAL features with servers free to support either, both, or neither.
このドキュメントでは（セクション5で）、[RFC5661]で現在標準化されているNFSv4の名前付き属性がxattrsの表現に適さない理由について説明します。代わりに、xattrsをサポートする別のプロトコルメカニズムについて説明します。結果として、xattrsと名前付き属性はどちらもオプションの機能になり、サーバーはどちらか一方、または両方を自由にサポートできます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Applications can store tracking information in extended attributes. Examples include storing metadata identifying the application that created the file, a tag to indicate when the file was last verified by a data integrity scrubber, or a tag to hold a checksum/crypto hash of the file contents along with the date of that signature. Xattrs can also be used for decorations or annotations. For example, a file downloaded from a web server can be tagged with the URL, which can be convenient if its source has to be determined in the future. Likewise, an email attachment, when saved, can be tagged with the message-id of the email, making it possible to trace the original message.
アプリケーションは拡張属性に追跡情報を保存できます。例としては、ファイルを作成したアプリケーションを識別するメタデータ、データ整合性スクラバーによってファイルが最後に検証された日時を示すタグ、ファイルの内容のチェックサム/暗号ハッシュをその署名の日付とともに保持するタグの保存などがあります。 Xattrsは、装飾や注釈にも使用できます。たとえば、WebサーバーからダウンロードされたファイルにURLでタグを付けることができます。これは、将来そのソースを特定する必要がある場合に便利です。同様に、電子メールの添付ファイルを保存すると、電子メールのメッセージIDでタグ付けできるため、元のメッセージを追跡できます。
Applications may need to behave differently when handling files of varying types. For example, file managers, such as GNOMEs, offer unique icons, different click behavior, and special lists of operations to perform depending on the file format. This can be achieved by looking at the file extension (Windows), or the type can be interpreted by inspecting it (Unix MIME type). Some file managers generate this information on the fly; others generate the information once and then cache it. Those that cache the information tend to put it in a custom database. The file manager must work to keep this database in sync with the files, which can change without the file manager's knowledge. A better approach is to dispense with the custom database and store such metadata in extended attributes. This is easier to maintain, provides faster access, and is readily accessible by applications [Love].
さまざまなタイプのファイルを処理する場合、アプリケーションの動作が異なる場合があります。たとえば、GNOMEなどのファイルマネージャは、独自のアイコン、さまざまなクリック動作、およびファイル形式に応じて実行する操作の特別なリストを提供します。これは、ファイル拡張子（Windows）を調べることで実現できます。または、タイプを調べることでタイプを解釈できます（Unix MIMEタイプ）。一部のファイルマネージャは、この情報を即座に生成します。他の人は情報を一度生成してからそれをキャッシュします。情報をキャッシュするものは、それをカスタムデータベースに置く傾向があります。ファイルマネージャは、このデータベースとファイルの同期を保つように機能する必要があります。ファイルマネージャは、ファイルマネージャの知らない間に変更される可能性があります。より良いアプローチは、カスタムデータベースを省いて、そのようなメタデータを拡張属性に格納することです。これは保守が簡単で、より高速なアクセスを提供し、アプリケーション[Love]から簡単にアクセスできます。
In addition to the prospect of data loss (discussed in Section 1) that arises from use of xattrs on local file systems, application use of xattrs poses further difficulties given the current lack of xattr support within NFSv4. As a result, certain applications may not be supported by NFSv4 or may be supported in an unsatisfactory way. Some examples are discussed below.
ローカルファイルシステムでのxattrsの使用から生じるデータ損失の可能性（セクション1で説明）に加えて、xattrsのアプリケーション使用は、NFSv4内のxattrサポートの現在の欠如を考えると、さらに困難をもたらします。その結果、特定のアプリケーションがNFSv4でサポートされないか、不十分な方法でサポートされる可能性があります。以下にいくつかの例を示します。
Swift, the OpenStack distributed object store, uses xattrs to store an object's metadata along with all the data together in one file. Swift-on-File [Swift] transfers the responsibility of maintaining object durability and availability to the underlying file system. At the time of writing, this requires a native file system client to mount the volumes. Xattr support in NFSv4 would open up the possibility of storing and consuming data from other storage systems and facilitate the migration of data between different backend storage systems.
OpenStack分散オブジェクトストアであるSwiftは、xattrsを使用して、オブジェクトのメタデータとすべてのデータを1つのファイルに格納します。 Swift-on-File [Swift]は、オブジェクトの耐久性と可用性を維持する責任を基盤となるファイルシステムに移します。執筆時点では、これには、ボリュームをマウントするネイティブファイルシステムクライアントが必要です。 NFSv4でのXattrサポートは、他のストレージシステムからのデータの保存と消費の可能性を開き、異なるバックエンドストレージシステム間でのデータの移行を容易にします。
Baloo, the file indexing and search framework for Key Distribution Exchange (KDE), has moved to storing metadata such as tags, ratings, and comments in file system xattrs instead of a custom database for simplicity. Starting with KDE Plasma 5.1, NFS is no longer supported due to its lack of xattr support [KDE].
Key Distribution Exchange（KDE）のファイルインデックス作成および検索フレームワークであるBalooは、タグ、評価、コメントなどのメタデータを、簡単にするためにカスタムデータベースではなくファイルシステムxattrsに格納するようになりました。 KDE Plasma 5.1以降、xattrサポートがないため[NFS]はサポートされなくなりました[KDE]。
Extended attributes are supported by most modern file systems.
拡張属性は、最新のほとんどのファイルシステムでサポートされています。
Some of the file systems that support extended attributes in Linux are as follows: ext3, ext4, JFS, XFS, and Btrfs. The getfattr and setfattr utilities can be used to retrieve and set xattrs. The names of the extended attributes must be prefixed by the name of the category and a dot; hence, these categories are generally qualified as namespaces. Currently, four namespaces exist: user, trusted, security, and system [Linux]. Recommendations on how they should be used have been published [freedesktop].
Linuxで拡張属性をサポートするファイルシステムには、ext3、ext4、JFS、XFS、およびBtrfsがあります。 getfattrおよびsetfattrユーティリティを使用して、xattrsを取得および設定できます。拡張属性の名前の前には、カテゴリーの名前とドットを付ける必要があります。したがって、これらのカテゴリは一般に名前空間として認定されます。現在、4つの名前空間が存在します：ユーザー、信頼済み、セキュリティ、およびシステム[Linux]。それらの使用方法に関する推奨事項が公開されました[freedesktop]。
FreeBSD supports extended attributes in two universal namespaces -- user and system -- although individual file systems are allowed to implement additional namespaces [FreeBSD].
FreeBSDは2つのユニバーサル名前空間（ユーザーとシステム）の拡張属性をサポートしていますが、個々のファイルシステムは追加の名前空間を実装できます[FreeBSD]。
Some file systems have facilities that are capable of storing both extended attributes and named attributes. For discussion regarding the relationship between these features, see Section 5. Solaris 9 and later provide file "forks", logically represented as files within a hidden directory that is associated with the target file [fsattr]. In the New Technology File System (NTFS), extended attributes may be stored within "file streams" [NTFS].
一部のファイルシステムには、拡張属性と名前付き属性の両方を格納できる機能があります。これらの機能の関係については、セクション5を参照してください。Solaris9以降では、ターゲットファイル[fsattr]に関連付けられた隠しディレクトリ内のファイルとして論理的に表されるファイル「フォーク」を提供しています。 New Technology File System（NTFS）では、拡張属性を「ファイルストリーム」[NTFS]に保存できます。
Xattrs can be retrieved and set through system calls or shell commands and are generally supported by user-space tools that preserve other file attributes. For example, the "rsync" remote copy program will correctly preserve user-extended attributes between Linux/ext4 and OSX/hfs by stripping off the Linux-specific "user." prefix.
Xattrsは、システムコールまたはシェルコマンドを介して取得および設定でき、通常、他のファイル属性を保持するユーザー空間ツールによってサポートされます。たとえば、「rsync」リモートコピープログラムは、Linux固有の「ユーザー」を削除することにより、Linux / ext4とOSX / hfsの間でユーザー拡張属性を正しく保持します。接頭辞。
Operating systems may define multiple "namespaces" in which xattrs can be set. Namespaces are more than organizational classes; the operating system may enforce different access policies and allow different capabilities depending on the namespace. Linux, for example, defines "security", "system", "trusted", and "user" namespaces, the first three being specific to Linux [freedesktop].
オペレーティングシステムは、xattrsを設定できる複数の「名前空間」を定義する場合があります。名前空間は、組織のクラス以上のものです。オペレーティングシステムは、さまざまなアクセスポリシーを適用し、名前空間に応じてさまざまな機能を許可します。たとえば、Linuxは「セキュリティ」、「システム」、「信頼された」、「ユーザー」の名前空間を定義し、最初の3つはLinux [freedesktop]に固有です。
Implementations generally agree on the semantics of a "user" namespace, which allows applications to store arbitrary user attribute data with file system objects. Access to this namespace is controlled via the normal file system attributes. As such, getting and setting xattrs from the user namespace can be considered interoperable across platforms and vendor implementations. Attributes from other namespaces are typically platform specific.
実装は一般に、「ユーザー」名前空間のセマンティクスに同意します。これにより、アプリケーションはファイルシステムオブジェクトとともに任意のユーザー属性データを格納できます。この名前空間へのアクセスは、通常のファイルシステム属性によって制御されます。そのため、ユーザー名前空間からxattrsを取得および設定することは、プラットフォームおよびベンダーの実装全体で相互運用可能であると見なすことができます。他の名前空間の属性は通常、プラットフォーム固有です。
This document provides support for namespaces related to user-managed metadata only, thus avoiding the need to specify the semantics applicable to particular system-interpreted xattrs. The values of xattrs are considered application data just as the contents of named attributes, files, and symbolic links are. Servers have a responsibility to store whatever value the client specifies and to return it on demand. Xattr keys and values MUST NOT be interpreted by the NFS clients and servers, as such behavior would lead to non-interoperable implementations. If there were a need to specify one or more attributes that servers need to act upon, the appropriate semantics would be specified by adding a new attribute for the purpose as provided for by [RFC5661] and [RFC8178].
このドキュメントは、ユーザー管理のメタデータのみに関連する名前空間のサポートを提供するため、特定のシステム解釈xattrsに適用可能なセマンティクスを指定する必要がありません。 xattrsの値は、名前付き属性、ファイル、およびシンボリックリンクの内容と同様に、アプリケーションデータと見なされます。サーバーには、クライアントが指定した値を保存し、要求に応じてそれを返す責任があります。 Xattrのキーと値は、NFSクライアントとサーバーで解釈してはなりません（MUST NOT）。このような動作は、相互運用できない実装につながるためです。サーバーが動作する必要がある1つ以上の属性を指定する必要がある場合、[RFC5661]と[RFC8178]で規定されている目的のために新しい属性を追加することにより、適切なセマンティクスを指定します。
[RFC7530] defines named attributes as opaque byte streams that are associated with a directory or file and referred to by a string name. Named attributes are intended to be used by client applications as a method to associate application-specific data with a regular file or directory. Although this makes xattrs similar in concept and use to named attributes, there are important semantic differences.
[RFC7530]は、名前付き属性を、ディレクトリまたはファイルに関連付けられ、文字列名で参照される不透明なバイトストリームとして定義します。名前付き属性は、アプリケーション固有のデータを通常のファイルまたはディレクトリに関連付ける方法としてクライアントアプリケーションで使用することを目的としています。これにより、xattrsの概念と使用法は名前付き属性と似ていますが、重要な意味上の違いがあります。
File systems typically define operations to get and set individual xattrs as being atomic, although collectively they may be independent. Xattrs generally have size limits ranging from a few bytes to several kilobytes; the maximum supported size is not universally defined and is usually restricted by the file system. Similar to Access Control Lists (ACLs), the amount of xattr data exchanged between the client and server for get/set operations can be considered to fit in a single COMPOUND request, bounded by the channel's negotiated maximum size for requests. Named attributes, on the other hand, are unbounded data streams and do not impose atomicity requirements.
ファイルシステムは通常、個々のxattrをアトミックとして取得および設定する操作を定義しますが、それらは集合的に独立している場合があります。 Xattrsには、通常、数バイトから数キロバイトまでのサイズ制限があります。サポートされる最大サイズは普遍的に定義されているわけではなく、通常はファイルシステムによって制限されます。アクセス制御リスト（ACL）と同様に、get / set操作のためにクライアントとサーバー間で交換されるxattrデータの量は、チャネルの要求のネゴシエートされた最大サイズによって制限される単一のCOMPOUND要求に収まると見なすことができます。一方、名前付き属性は無制限のデータストリームであり、原子性の要件を課しません。
Individual named attributes are analogous to files and are opened and closed just as files are. Caching of the data for these needs to be handled just as data caching is for ordinary files following close-to-open semantics. Xattrs, on the other hand, have caching requirements similar to other file attributes.
個々の名前付き属性はファイルに類似しており、ファイルと同じように開いたり閉じたりします。これらのデータのキャッシングは、データキャッシングが通常のファイルのクローズツーオープンセマンティクスに従うのと同じように処理する必要があります。一方、Xattrsには、他のファイル属性と同様のキャッシュ要件があります。
Named attributes and xattrs have different semantics and are treated by applications as belonging to disjoint namespaces. As a result, mapping from one to the other would be, at best, a compromise. Despite these differences, the underlying file system structure used to store named attributes is generally capable of storing xattrs. However, the converse is typically not the case because of the size limits applicable to xattrs.
名前付き属性とxattrsは異なるセマンティクスを持ち、アプリケーションによって非結合名前空間に属しているものとして扱われます。結果として、一方から他方へのマッピングは、せいぜい妥協に過ぎません。これらの違いにもかかわらず、名前付き属性の格納に使用される基本的なファイルシステム構造は、一般にxattrsを格納できます。ただし、xattrsに適用されるサイズ制限のため、通常はその逆は当てはまりません。
While it might be possible to write guidance about how a client can use the named attribute mechanism to act like xattrs, such as by carving out some namespace and specifying locking primitives to enforce atomicity constraints on individual get/set operations, such an approach is sufficiently problematic; thus, it will not be attempted here. A client application trying to use xattrs through named attributes with a server that supported xattrs directly would get a lower level of service and could fail to cooperate on a local application running on the server unless the server file system defined its own interoperability constraints. File systems that already implement xattrs and named attributes natively would need additional guidance such as reserving a named attribute namespace specifically for implementation purposes.
クライアントが名前付き属性メカニズムを使用してxattrsのように動作する方法に関するガイダンスを書くことは可能かもしれません（たとえば、名前空間を切り分けてロックプリミティブを指定して、個々のget / set操作に原子性の制約を適用するなど）、そのようなアプローチは十分です問題がある;したがって、ここでは試行されません。 xattrsを直接サポートするサーバーで名前付き属性を介してxattrsを使用しようとするクライアントアプリケーションは、サービスのレベルが低くなり、サーバーファイルシステムが独自の相互運用性制約を定義しない限り、サーバーで実行されているローカルアプリケーションでの連携に失敗する可能性があります。 xattrsと名前付き属性をすでにネイティブに実装しているファイルシステムでは、特に実装目的で名前付き属性の名前空間を予約するなど、追加のガイダンスが必要になります。
This document contains the External Data Representation (XDR) [RFC4506] description of the extended attributes. The XDR description is embedded in this document in a way that makes it simple for the reader to extract into a ready-to-compile form. The reader can feed this document into the following shell script to produce the machine-readable XDR description of extended attributes:
このドキュメントには、拡張属性の外部データ表現（XDR）[RFC4506]の説明が含まれています。 XDRの説明は、読者がコンパイル可能なフォームに簡単に抽出できるように、このドキュメントに埋め込まれています。読者はこのドキュメントを次のシェルスクリプトにフィードして、拡張属性の機械可読なXDR記述を生成できます。
<CODE BEGINS>
<コード開始>
#! /bin/sh
grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'
<CODE ENDS> That is, if the above script is stored in a file called "extract.sh", and this document is in a file called "spec.txt", then the reader can do:
<CODE ENDS>つまり、上記のスクリプトが「extract.sh」というファイルに保存されており、このドキュメントが「spec.txt」というファイルにある場合、リーダーは次のことを実行できます。
sh extract.sh < spec.txt > xattr_prot.x
sh extract.sh <spec.txt> xattr_prot.x
The effect of the script is to remove leading white space from each line, plus a sentinel sequence of "///".
スクリプトの効果は、各行から先頭の空白と、 "///"のセンチネルシーケンスを削除することです。
The initial section of the embedded XDR file header follows. Subsequent XDR descriptions, with the sentinel sequence, are embedded throughout the document.
埋め込まれたXDRファイルヘッダーの最初のセクションが続きます。センチネルシーケンスを含む後続のXDR記述は、ドキュメント全体に埋め込まれています。
Note that the XDR code contained in this document depends on types from the NFSv4.2 nfs4_prot.x file [RFC7863]. This includes both nfs types that end with a 4, such as nfs_cookie4, count4, etc., as well as more-generic types, such as opaque and bool.
このドキュメントに含まれるXDRコードは、NFSv4.2 nfs4_prot.xファイル[RFC7863]のタイプに依存することに注意してください。これには、nfs_cookie4、count4など、4で終わるnfsタイプと、opaqueやboolなどのより一般的なタイプの両方が含まれます。
To produce a compilable XDR file, the following procedure is suggested:
コンパイル可能なXDRファイルを作成するには、次の手順をお勧めします。
o Extract the file nfs4_prot.x as described in [RFC7863].
o [RFC7863]の説明に従って、ファイルnfs4_prot.xを抽出します。
o Extract xattr_prot.x from this document as described above.
o 上記のように、このドキュメントからxattr_prot.xを抽出します。
o Apply any changes required for other extensions to be included together with the xattr extension.
o 他の拡張機能をxattr拡張機能と一緒に含めるために必要な変更を適用します。
o Perform modifications to nfs4_prot.x as described by comments within xattr_prot.x.
o xattr_prot.x内のコメントで説明されているように、nfs4_prot.xに変更を加えます。
o Extend the unions nfs_argop4 and nfs_resop4 to include cases for the new operations defined in this document.
o ユニオンnfs_argop4およびnfs_resop4を拡張して、このドキュメントで定義されている新しい操作のケースを含めます。
o Combine the XDR files for the base NFSv4.2 protocol and all needed extensions by either concatenating the relevant XDR files or using file inclusion.
o 関連するXDRファイルを連結するか、ファイルインクルードを使用して、ベースNFSv4.2プロトコルのXDRファイルと必要なすべての拡張機能を結合します。
Both the XDR description and the scripts used for extracting the XDR description are Code Components as described in "Legal Provisions Relating to IETF Documents", Section 4 of [LEGAL]. These Code Components are licensed according to the terms of that document.
[LEGAL]のセクション4の「IETFドキュメントに関連する法的規定」で説明されているように、XDR記述とXDR記述の抽出に使用されるスクリプトはどちらもコードコンポーネントです。これらのコードコンポーネントは、そのドキュメントの条件に従ってライセンスされます。
<CODE BEGINS>
<コード開始>
/// /*
/// * Copyright (c) 2017 IETF Trust and the persons identified
/// * as authors of the code. All rights reserved.
/// *
/// * Redistribution and use in source and binary forms, with
/// * or without modification, are permitted provided that the
/// * following conditions are met:
/// *
/// * o Redistributions of source code must retain the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer.
/// *
/// * o Redistributions in binary form must reproduce the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer in the documentation and/or other
/// * materials provided with the distribution.
/// *
/// * o Neither the name of Internet Society, IETF or IETF
/// * Trust, nor the names of specific contributors, may be
/// * used to endorse or promote products derived from this
/// * software without specific prior written permission.
/// *
/// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
/// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
/// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
/// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
/// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
/// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
/// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
/// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
/// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
/// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
/// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
/// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
/// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
/// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/// *
/// * This code was derived from RFC 8276.
/// * Please reproduce this note if possible.
/// */
<CODE ENDS>
<コード終了>
<CODE BEGINS>
<コード開始>
/// /*
/// * xattr_prot.x
/// */
/// /*
/// * The following includes statements that are for example only.
/// * The actual XDR definition files are generated separately
/// * and independently and are likely to have a different name.
/// * %#include <rpc_prot.x>
/// * %#include <nfsv42.x>
/// */
<CODE ENDS>
<コード終了>
This section documents extensions to the NFSv4 protocol operations to allow xattrs to be queried and modified by clients. A new attribute is added to allow clients to determine if the file system being accessed provides support for xattrs. New operations are defined to allow xattr keys and values to be queried and set. In addition, the ACCESS operation is extended by adding new mask bits to provide access information relating to xattrs.
このセクションでは、クライアントがxattrsを照会および変更できるようにするNFSv4プロトコル操作の拡張について説明します。アクセスされるファイルシステムがxattrsのサポートを提供するかどうかをクライアントが判断できるように、新しい属性が追加されました。 xattrキーと値を照会および設定できるように、新しい操作が定義されています。さらに、ACCESS操作は、xattrsに関連するアクセス情報を提供する新しいマスクビットを追加することで拡張されます。
These changes follow applicable guidelines for valid NFSv4 XDR protocol extension, as specified in [RFC8178], and obey the rules for extensions capable of being made without a change in minor version number.
これらの変更は、[RFC8178]で指定されている有効なNFSv4 XDRプロトコル拡張の適用可能なガイドラインに従い、マイナーバージョン番号を変更せずに実行できる拡張のルールに従います。
<CODE BEGINS>
<コード開始>
/// typedef component4 xattrkey4;
/// typedef opaque xattrvalue4<>;
<CODE ENDS>
<コード終了>
Each xattr is a key/value pair. xattrkey4 is a string denoting the xattr key name and an attrvalue4, which is a variable-length string that identifies the value of the xattr. The handling of xattrkey4 with regard to internationalization-related issues is the same as that for NFSv4 file names and named attribute names, as described in [RFC7530]. Any regular file or directory may have a set of extended attributes, each consisting of a key and associated value. The NFS client or server MUST NOT interpret the contents of xattrkey4 or xattrvalue4.
各xattrはキーと値のペアです。 xattrkey4は、xattrキー名を示す文字列と、attrvalue4です。これは、xattrの値を識別する可変長文字列です。国際化関連の問題に関するxattrkey4の処理は、[RFC7530]で説明されているように、NFSv4ファイル名と名前付き属性名の処理と同じです。通常のファイルまたはディレクトリには、一連の拡張属性があり、それぞれがキーと関連する値で構成されています。 NFSクライアントまたはサーバーは、xattrkey4またはxattrvalue4の内容を解釈してはなりません（MUST NOT）。
The per-fs read-only attribute described below may be used to determine if xattrs are supported. Servers need not support this attribute, and some NFSv4.2 servers may be unaware of its existence. Before interrogating this attribute using GETATTR, a client should determine whether it is a supported attribute by interrogating the supported_attrs attribute.
以下で説明するfsごとの読み取り専用属性を使用して、xattrsがサポートされているかどうかを確認できます。サーバーはこの属性をサポートする必要はなく、一部のNFSv4.2サーバーはその存在を認識しない場合があります。 GETATTRを使用してこの属性を照会する前に、クライアントは、supported_attrs属性を照会して、それがサポートされている属性かどうかを判別する必要があります。
xattr_support is set to True, if the object's file system supports extended attributes.
オブジェクトのファイルシステムが拡張属性をサポートしている場合、xattr_supportはTrueに設定されます。
Since xattr_support is not a REQUIRED attribute, the server need not support it. However, a client may reasonably assume that a server (or file system) that does not support the xattr_support attribute does not provide xattr support, and it acts on that basis.
xattr_supportは必須属性ではないため、サーバーはそれをサポートする必要はありません。ただし、クライアントは、xattr_support属性をサポートしないサーバー（またはファイルシステム）がxattrサポートを提供しないと合理的に想定する場合があり、それに基づいて動作します。
Note that the protocol does not enforce any limits on the number of keys, the length of a key, the size of a value, or the total size of xattrs that are allowed for a file. The server file system MAY impose additional limits. In addition, a single xattr key or value exchanged between the client and server for get/set operations is limited by the channel's negotiated maximum size for requests and responses.
このプロトコルでは、ファイルに許可されるキーの数、キーの長さ、値のサイズ、またはxattrsの合計サイズに制限はありません。サーバーファイルシステムは、追加の制限を課してもよい（MAY）。さらに、get / set操作のためにクライアントとサーバー間で交換される単一のxattrキーまたは値は、要求と応答のチャネルのネゴシエートされた最大サイズによって制限されます。
<CODE BEGINS>
<コード開始>
/// /* Following lines are to be added to enum nfsstat4 */
/// /*
/// NFS4ERR_NOXATTR = 10095, /* xattr does not exist */
/// NFS4ERR_XATTR2BIG = 10096 /* xattr value is too big */
/// */
<CODE ENDS>
<コード終了>
The specified xattr does not exist or the server is unable to retrieve it.
指定されたxattrが存在しないか、サーバーがそれを取得できません。
The size of the xattr value specified as part of a SETXATTR operation, or the collective size of all xattrs of the file resulting from the SETXATTR operation, is bigger than that supported by the underlying file system.
SETXATTR操作の一部として指定されたxattr値のサイズ、またはSETXATTR操作の結果であるファイルのすべてのxattrの合計サイズは、基礎となるファイルシステムでサポートされているサイズよりも大きくなります。
Applications need to perform the following operations on a given file's extended attributes [Love]:
アプリケーションは、特定のファイルの拡張属性[愛]に対して次の操作を実行する必要があります。
o Given a file, return a list of all of the file's assigned extended attribute keys.
o ファイルを指定すると、ファイルに割り当てられているすべての拡張属性キーのリストを返します。
o Given a file and a key, return the corresponding value.
o ファイルとキーを指定して、対応する値を返します。
o Given a file, a key, and a value, assign that value to the key.
o ファイル、キー、および値を指定して、その値をキーに割り当てます。
o Given a file and a key, remove that extended attribute from the file.
o ファイルとキーを指定して、その拡張属性をファイルから削除します。
In order to meet these requirements, this section introduces four new OPTIONAL operations: GETXATTR, SETXATTR, LISTXATTRS and REMOVEXATTR. These operations are to query, set, list, and remove xattrs, respectively. A server MUST support all four operations when they are directed to a file system that supports the xattr_support attribute and returns TRUE when it is interrogated. For file systems that either do not support the xattr_support attribute or return FALSE when the xattr_support attribute is interrogated, all of the above operations MUST NOT be supported. GETXATTR allows obtaining the value of an xattr key, SETXATTR allows creating or replacing an xattr key with a value, LISTXATTRS enumerates all the xattrs names, and REMOVEXATTR allows deleting a single xattr.
これらの要件を満たすために、このセクションでは、GETXATTR、SETXATTR、LISTXATTRS、およびREMOVEXATTRの4つの新しいOPTIONAL操作を紹介します。これらの操作は、xattrsをそれぞれ照会、設定、リスト、および削除することです。サーバーは、xattr_support属性をサポートするファイルシステムを対象とする場合、4つの操作すべてをサポートしなければならず、照会されるとTRUEを返します。 xattr_support属性をサポートしていないか、xattr_support属性が照会されたときにFALSEを返すファイルシステムの場合、上記の操作はすべてサポートしてはなりません（MUST NOT）。 GETXATTRはxattrキーの値の取得を許可し、SETXATTRはxattrキーの作成または値への置換を許可し、LISTXATTRSはすべてのxattrs名を列挙し、REMOVEXATTRは単一のxattrの削除を許可します。
Note that some server implementations may not be aware of the existence of these operations, thereby a client cannot always expect that issuing one of them will either succeed or return NFS4ERR_NOTSUPP. In some cases, NFS4ERR_OP_ILLEGAL may be returned or the request may encounter an XDR decode error on the server. As a result, clients should only issue these operations after determining that support is present.
一部のサーバー実装はこれらの操作の存在を認識していない場合があることに注意してください。そのため、クライアントは、いずれかの操作の発行が成功するか、NFS4ERR_NOTSUPPを返すとは必ずしも期待できません。場合によっては、NFS4ERR_OP_ILLEGALが返されるか、リクエストでサーバー上でXDRデコードエラーが発生することがあります。その結果、クライアントは、サポートが存在することを確認した後でのみ、これらの操作を発行する必要があります。
<CODE BEGINS>
<コード開始>
/// struct GETXATTR4args {
/// /* CURRENT_FH: file */
/// xattrkey4 gxa_name;
/// };
<CODE ENDS>
<コード終了>
<CODE BEGINS>
<コード開始>
/// union GETXATTR4res switch (nfsstat4 gxr_status) {
/// case NFS4_OK:
/// xattrvalue4 gxr_value;
/// default:
/// void;
/// };
<CODE ENDS>
<コード終了>
The GETXATTR operation will obtain the value for the given extended attribute key for the file system object specified by the current filehandle.
GETXATTR操作は、現在のファイルハンドルで指定されたファイルシステムオブジェクトの特定の拡張属性キーの値を取得します。
The server will fetch the xattr value for the key that the client requests if xattrs are supported by the server for the target file system. If the server does not support xattrs on the target file system, then it MUST NOT return a value and MUST return the NFS4ERR_NOTSUPP error or another error indicating the request was not understood. The server also MUST return NFS4ERR_NOXATTR if it supports xattrs on the target but cannot obtain the requested data. If the xattr value contained in the server response is such as to cause the channel's negotiated maximum response size to be exceeded, then the server MUST return NFS4ERR_REP_TOO_BIG in gxr_status.
ターゲットファイルシステムのサーバーでxattrsがサポートされている場合、サーバーは、クライアントが要求するキーのxattr値をフェッチします。サーバーがターゲットファイルシステムでxattrsをサポートしていない場合、値を返してはならず、NFS4ERR_NOTSUPPエラーまたは要求が理解されなかったことを示す別のエラーを返さなければなりません（MUST）。サーバーは、ターゲットでxattrsをサポートしているが、要求されたデータを取得できない場合も、NFS4ERR_NOXATTRを返さなければなりません（MUST）。サーバー応答に含まれるxattr値が、チャネルのネゴシエートされた最大応答サイズを超えるようなものである場合、サーバーはgxr_statusでNFS4ERR_REP_TOO_BIGを返す必要があります。
Clients that have cached an xattr may avoid the need to do a GETXATTR by determining if the change attribute is the same as it was when the xattr was fetched. If the client does not hold a delegation for the file in question, it can obtain the change attribute with a GETATTR request and compare that change attribute's value to the change attribute value fetched when the xattr value was obtained. This handling is similar to how a client would revalidate other file attributes such as ACLs.
xattrをキャッシュしたクライアントは、変更属性がxattrがフェッチされたときと同じであるかどうかを判別することにより、GETXATTRを実行する必要を回避できます。問題のファイルの委任をクライアントが保持していない場合、クライアントはGETATTR要求で変更属性を取得し、その変更属性の値を、xattr値の取得時にフェッチされた変更属性値と比較できます。この処理は、クライアントがACLなどの他のファイル属性を再検証する方法に似ています。
When responding to such a GETATTR, the server will, if there is an OPEN_DELEGATE_WRITE delegation held by another client for the file in question, either obtain the actual current value of these attributes from the client holding the delegation by using the CB_GETATTR callback or revoke the delegation. See Section 18.7.4 of [RFC5661] for details.
そのようなGETATTRに応答するとき、サーバーは、問題のファイルに対して別のクライアントによって保持されているOPEN_DELEGATE_WRITE委任がある場合、委任を保持しているクライアントからCB_GETATTRコールバックを使用してこれらの属性の実際の現在値を取得するか、または委任。詳細については、[RFC5661]のセクション18.7.4を参照してください。
<CODE BEGINS>
<コード開始>
/// enum setxattr_option4 {
/// SETXATTR4_EITHER = 0,
/// SETXATTR4_CREATE = 1,
/// SETXATTR4_REPLACE = 2
/// };
/// struct SETXATTR4args {
/// /* CURRENT_FH: file */
/// setxattr_option4 sxa_option;
/// xattrkey4 sxa_key;
/// xattrvalue4 sxa_value;
/// };
<CODE ENDS>
<コード終了>
<CODE BEGINS>
<コード開始>
/// union SETXATTR4res switch (nfsstat4 sxr_status) {
/// case NFS4_OK:
/// change_info4 sxr_info;
/// default:
/// void;
/// };
<CODE ENDS>
<コード終了>
The SETXATTR operation changes one extended attribute of a file system object. The change desired is specified by sxa_option. SETXATTR4_CREATE is used to associate the given value with the given extended attribute key for the file system object specified by the current filehandle. The server MUST return NFS4ERR_EXIST if the attribute key already exists. SETXATTR4_REPLACE is also used to set an xattr, but the server MUST return NFS4ERR_NOXATTR if the attribute key does not exist. By default (SETXATTR4_EITHER), the extended attribute will be created if need be, or its value will be replaced if the attribute exists.
SETXATTR操作は、ファイルシステムオブジェクトの1つの拡張属性を変更します。必要な変更は、sxa_optionで指定されます。 SETXATTR4_CREATEは、現在のファイルハンドルで指定されたファイルシステムオブジェクトの特定の拡張属性キーに特定の値を関連付けるために使用されます。属性キーがすでに存在する場合、サーバーはNFS4ERR_EXISTを返す必要があります。 SETXATTR4_REPLACEはxattrの設定にも使用されますが、属性キーが存在しない場合、サーバーはNFS4ERR_NOXATTRを返さなければなりません（MUST）。デフォルト（SETXATTR4_EITHER）では、必要に応じて拡張属性が作成されるか、属性が存在する場合はその値が置き換えられます。
If the xattr key and value contained in the client request are such that the request would exceed the channel's negotiated maximum request size, then the server MUST return NFS4ERR_REQ_TOO_BIG in sxr_status. If the server file system imposes additional limits on the size of the key name or value, it MAY return NFS4ERR_XATTR2BIG.
クライアント要求に含まれるxattrキーと値が、要求がチャネルのネゴシエートされた最大要求サイズを超えるようなものである場合、サーバーはsxr_statusでNFS4ERR_REQ_TOO_BIGを返さなければなりません（MUST）。サーバーのファイルシステムがキーの名前または値のサイズに追加の制限を課している場合、NFS4ERR_XATTR2BIGを返す場合があります。
A successful SETXATTR MUST change the file time_metadata and change attributes if the xattr is created or the value assigned to xattr changes. However, it is not necessary to change these attributes if there has been no actual change in the xattr value. Avoiding attribute change in such situations is desirable as it avoids unnecessary cache invalidation.
xattrが作成された場合、またはxattrに割り当てられた値が変更された場合、SETXATTRが成功すると、ファイルtime_metadataを変更し、属性を変更する必要があります。ただし、xattr値が実際に変更されていない場合は、これらの属性を変更する必要はありません。そのような状況で属性の変更を回避することは、不要なキャッシュの無効化を回避するために望ましいです。
On success, the server returns the change_info4 information in sxr_info. With the atomic field of the change_info4 data type, the server will indicate if the before and after change attributes were obtained atomically with respect to the SETXATTR operation. This allows the client to determine if its cached xattrs are still valid after the operation. See Section 8.7 for a discussion on xattr caching.
成功すると、サーバーはsxr_infoでchange_info4情報を返します。 change_info4データ型のアトミックフィールドを使用すると、サーバーは、変更前および変更後の属性がSETXATTR操作に関してアトミックに取得されたかどうかを示します。これにより、クライアントは、キャッシュされたxattrsが操作後も有効かどうかを判断できます。 xattrキャッシングについては、8.7項を参照してください。
If the object whose xattr is being changed has a file delegation that is held by a client other than the one doing the SETXATTR, the delegation(s) must be recalled, and the operation cannot proceed to actually change the xattr until each such delegation is returned or revoked. In all cases in which delegations are recalled, the server is likely to return one or more NFS4ERR_DELAY errors while the delegation(s) remains outstanding, although it might not do that if the delegations are returned quickly.
xattrが変更されているオブジェクトに、SETXATTRを実行しているクライアント以外のクライアントが保持しているファイル委任がある場合、委任を再呼び出しする必要があり、そのような委任が完了するまで、操作は実際にxattrを変更することはできません。返却または取り消されました。委任がリコールされるすべての場合において、サーバーは、委任が未処理のままである間、1つ以上のNFS4ERR_DELAYエラーを返す可能性がありますが、委任が迅速に返された場合はそうではありません。
<CODE BEGINS>
<コード開始>
/// struct LISTXATTRS4args {
/// /* CURRENT_FH: file */
/// nfs_cookie4 lxa_cookie;
/// count4 lxa_maxcount;
/// };
<CODE ENDS>
<コード終了>
<CODE BEGINS>
<コード開始>
/// struct LISTXATTRS4resok {
/// nfs_cookie4 lxr_cookie;
/// xattrkey4 lxr_names<>;
/// bool lxr_eof;
/// };
/// union LISTXATTRS4res switch (nfsstat4 lxr_status) {
/// case NFS4_OK:
/// LISTXATTRS4resok lxr_value;
/// default:
/// void;
/// };
<CODE ENDS>
<コード終了>
The LISTXATTRS operation retrieves a variable number of extended attribute keys from the file system object specified by the current filehandle, along with information to allow the client to request additional attribute keys in a subsequent LISTXATTRS.
LISTXATTRS操作は、現在のファイルハンドルで指定されたファイルシステムオブジェクトから可変数の拡張属性キーを取得します。また、クライアントが後続のLISTXATTRSで追加の属性キーを要求できるようにするための情報も取得します。
The arguments contain a cookie value that represents where the LISTXATTRS should start within the list of xattrs. A value of 0 (zero) for lxa_cookie is used to start reading at the beginning of the list. For subsequent LISTXATTRS requests, the client specifies a cookie value that is provided by the server on a previous LISTXATTRS request.
引数には、LISTXATTRSがxattrsのリスト内のどこから始まるかを表すcookie値が含まれています。 lxa_cookieの値0（ゼロ）は、リストの先頭から読み取りを開始するために使用されます。後続のLISTXATTRS要求の場合、クライアントは、前のLISTXATTRS要求でサーバーによって提供されたCookie値を指定します。
The lxa_maxcount value of the argument is the maximum number of bytes for the result. This maximum size represents all of the data being returned within the LISTXATTRS4resok structure and includes the XDR overhead. The server may return less data. If the server is unable to return a single xattr name within the maxcount limit, the error NFS4ERR_TOOSMALL will be returned to the client.
引数のlxa_maxcount値は、結果の最大バイト数です。この最大サイズは、LISTXATTRS4resok構造内で返されるすべてのデータを表し、XDRオーバーヘッドが含まれます。サーバーが返すデータが少なくなる場合があります。サーバーがmaxcount制限内で単一のxattr名を返すことができない場合、エラーNFS4ERR_TOOSMALLがクライアントに返されます。
On successful return, the server's response will provide a list of extended attribute keys. The "lxr_eof" flag has a value of TRUE if there are no more keys for the object.
正常に戻ると、サーバーの応答は拡張属性キーのリストを提供します。オブジェクトのキーがなくなった場合、「lxr_eof」フラグの値はTRUEになります。
The cookie value is only meaningful to the server and is used as a "bookmark" for the xattr key. As mentioned, this cookie is used by the client for subsequent LISTXATTRS operations so that it may continue listing keys. The cookie is similar in concept to a READDIR cookie or the READ offset but should not be interpreted as such by the client.
cookie値はサーバーにとってのみ意味があり、xattrキーの「ブックマーク」として使用されます。前述のように、このCookieはクライアントが後続のLISTXATTRS操作に使用するため、キーのリストを継続できます。 Cookieは、概念的にはREADDIR CookieまたはREADオフセットに似ていますが、クライアントによって解釈されるべきではありません。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルはその値を保持します。
The handling of a cookie is similar to that of the READDIR operation. It should be a rare occurrence that a server is unable to continue properly listing xattrs with the provided cookie. The server should make every effort to avoid this condition since the application at the client may not be able to properly handle this type of failure.
Cookieの処理は、READDIR操作の処理と似ています。サーバーが提供されたcookieでxattrsを適切にリストし続けることができないのはまれなことです。クライアントのアプリケーションはこのタイプの障害を適切に処理できない可能性があるため、サーバーはこの状態を回避するためにあらゆる努力をする必要があります。
<CODE BEGINS>
<コード開始>
/// struct REMOVEXATTR4args {
/// /* CURRENT_FH: file */
/// xattrkey4 rxa_name;
/// };
<CODE ENDS>
<コード終了>
<CODE BEGINS>
<コード開始>
/// union REMOVEXATTR4res switch (nfsstat4 rxr_status) {
/// case NFS4_OK:
/// change_info4 rxr_info;
/// default:
/// void;
/// };
<CODE ENDS>
<コード終了>
The REMOVEXATTR operation deletes one extended attribute of a file system object specified by rxa_name. The server MUST return NFS4ERR_NOXATTR if the attribute key does not exist.
REMOVEXATTR操作は、rxa_nameで指定されたファイルシステムオブジェクトの1つの拡張属性を削除します。属性キーが存在しない場合、サーバーはNFS4ERR_NOXATTRを返す必要があります。
A successful REMOVEXATTR MUST change the file time_metadata and change attributes.
REMOVEXATTRが成功すると、ファイルtime_metadataを変更し、属性を変更する必要があります。
Similar to SETXATTR, the server communicates the value of the change attribute immediately prior to, and immediately following, a successful REMOVEXATTR operation in rxr_info. This allows the client to determine if its cached xattrs are still valid after the operation. See Section 8.7 for a discussion on xattr caching.
SETXATTRと同様に、サーバーは、rxr_infoでREMOVEXATTR操作が成功する直前および直後に、変更属性の値を通知します。これにより、クライアントは、キャッシュされたxattrsが操作後も有効かどうかを判断できます。 xattrキャッシングについては、8.7項を参照してください。
If the object whose xattr is being removed has a file delegation that is held by a client other than the one doing the REMOVEXATTR, the delegation(s) must be recalled, and the operation cannot proceed to delete the xattr until each such delegation is returned or revoked. In all cases in which delegations are recalled, the server is likely to return one or more NFS4ERR_DELAY errors while the delegation(s) remains outstanding, although it might not do that if the delegations are returned quickly.
xattrが削除されているオブジェクトに、REMOVEXATTRを実行しているクライアント以外のクライアントによって保持されているファイル委任がある場合、委任を再呼び出しする必要があり、そのような委任が返されるまで、操作はxattrの削除に進むことができません。または取り消されました。委任がリコールされるすべての場合において、サーバーは、委任が未処理のままである間、1つ以上のNFS4ERR_DELAYエラーを返す可能性がありますが、委任が迅速に返された場合はそうではありません。
This section contains a table that gives the valid error returns for each new protocol operation. The error code NFS4_OK (indicating no error) is not listed but should be understood to be returnable by all new operations. The error values for all other operations are defined in Section 13.2 of [RFC7530] and Section 11.2 of [RFC7862].
このセクションには、新しいプロトコル操作ごとに有効なエラーが返される表が含まれています。エラーコードNFS4_OK（エラーがないことを示す）はリストされていませんが、すべての新しい操作で返されると理解されているはずです。他のすべての操作のエラー値は、[RFC7530]のセクション13.2および[RFC7862]のセクション11.2で定義されています。
+-------------+-----------------------------------------------------+
| Operation | Errors |
+-------------+-----------------------------------------------------+
| GETXATTR | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_NOXATTR, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_WRONG_TYPE |
| SETXATTR | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, NFS4ERR_BADXDR, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXIST, NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOXATTR, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE, |
| | NFS4ERR_XATTR2BIG |
| LISTXATTRS | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_NOXATTR, |
| | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM, |
| | NFS4ERR_REP_TOO_BIG, NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
| REMOVEXATTR | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, NFS4ERR_BADXDR, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXIST, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_LOCKED, NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOXATTR,, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_PERM, NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+-------------+-----------------------------------------------------+
Valid Error Returns for Each New Protocol Operation
新しいプロトコル操作ごとに有効なエラーが返される
In order to provide fine-grained access control to query or modify extended attributes, new access rights are defined that can be checked to determine if the client is permitted to perform the xattr operation.
拡張属性を照会または変更するためのきめの細かいアクセス制御を提供するために、クライアントがxattr操作の実行を許可されているかどうかを判別するために検査できる新しいアクセス権が定義されています。
Note that in general, as explained in Section 18.1.4 of [RFC5661], a client cannot reliably perform an access check with only current file attributes and must verify access with the server.
一般に、[RFC5661]のセクション18.1.4で説明されているように、クライアントは現在のファイル属性のみでアクセスチェックを確実に実行することはできず、サーバーとのアクセスを確認する必要があることに注意してください。
This section extends the semantics of the ACCESS operation documented in Section 18.1 of [RFC5661]. Three new access permissions can be requested:
このセクションでは、[RFC5661]のセクション18.1に記載されているACCESS操作のセマンティクスを拡張します。 3つの新しいアクセス許可をリクエストできます。
ACCESS4_XAREAD Query a file or directory for its xattr value given a key.
ACCESS4_XAREADキーを指定して、ファイルまたはディレクトリにxattr値を問い合わせます。
ACCESS4_XAWRITE Modify xattr keys and/or values of a file or directory.
ACCESS4_XAWRITEファイルまたはディレクトリのxattrキーや値を変更します。
ACCESS4_XALIST Query a file or directory to list its xattr keys.
ACCESS4_XALISTファイルまたはディレクトリを照会して、そのxattrキーをリストします。
As with the existing access permissions, the results of ACCESS are advisory in nature, with no implication that such access will be allowed or denied in the future.
既存のアクセス許可と同様に、ACCESSの結果は本質的に助言であり、そのようなアクセスが将来許可または拒否されることを意味するものではありません。
The rules for the client and server follow:
クライアントとサーバーのルールは次のとおりです。
o If the client is sending ACCESS in order to determine if the user can read an xattr of the file with GETXATTR, the client should set ACCESS4_XAREAD in the request's access field.
o ユーザーがGETXATTRを使用してファイルのxattrを読み取ることができるかどうかを判断するためにクライアントがACCESSを送信している場合、クライアントはリクエストのアクセスフィールドにACCESS4_XAREADを設定する必要があります。
o If the client is sending ACCESS in order to determine if the user can modify an xattr of the file with SETXATTR or REMOVEXATTR, the client should set ACCESS4_XAWRITE in the request's access field.
o ユーザーがSETXATTRまたはREMOVEXATTRを使用してファイルのxattrを変更できるかどうかを判断するためにクライアントがACCESSを送信している場合、クライアントはリクエストのアクセスフィールドにACCESS4_XAWRITEを設定する必要があります。
o If the client is sending ACCESS in order to determine if the user can list the xattr keys of the file with LISTXATTRS, the client should set ACCESS4_XALIST in the request's access field.
o ユーザーがLISTXATTRSを使用してファイルのxattrキーをリストできるかどうかを判断するためにクライアントがACCESSを送信している場合、クライアントはリクエストのアクセスフィールドにACCESS4_XALISTを設定する必要があります。
This section lists the numeric values that are assigned new attributes and operations to implement the xattr feature. To avoid inconsistent assignments, these have been checked against the most recent protocol version [RFC5661] and the current minor version [RFC7862]. Development of interoperable prototypes is possible using these values.
このセクションでは、xattr機能を実装するために新しい属性と操作が割り当てられる数値を示します。一貫性のない割り当てを回避するために、これらは最新のプロトコルバージョン[RFC5661]および現在のマイナーバージョン[RFC7862]に対してチェックされています。これらの値を使用して、相互運用可能なプロトタイプの開発が可能です。
<CODE BEGINS>
<コード開始>
/// /*
/// * ACCESS - Check Access Rights
/// */
/// const ACCESS4_XAREAD = 0x00000040;
/// const ACCESS4_XAWRITE = 0x00000080;
/// const ACCESS4_XALIST = 0x00000100;
/// /*
/// * New NFSv4 attribute
/// */
/// typedef bool fattr4_xattr_support;
/// /*
/// * New RECOMMENDED Attribute
/// */
/// const FATTR4_XATTR_SUPPORT = 82;
/// /*
/// * New NFSv4 operations
/// */
/// /* Following lines are to be added to enum nfs_opnum4 */
/// /*
/// OP_GETXATTR = 72,
/// OP_SETXATTR = 73,
/// OP_LISTXATTRS = 74,
/// OP_REMOVEXATTR = 75,
/// */
/// /*
/// * New cases for Operation arrays
/// */
/// /* Following lines are to be added to nfs_argop4 */
/// /*
/// case OP_GETXATTR: GETXATTR4args opgetxattr;
/// case OP_SETXATTR: SETXATTR4args opsetxattr;
/// case OP_LISTXATTRS: LISTXATTRS4args oplistxattrs;
/// case OP_REMOVEXATTR: REMOVEXATTR4args opremovexattr;
/// */
/// /* Following lines are to be added to nfs_resop4 */
/// /*
/// case OP_GETXATTR: GETXATTR4res opgetxattr;
/// case OP_SETXATTR: SETXATTR4res opsetxattr;
/// case OP_LISTXATTRS: LISTXATTRS4res oplistxattrs;
/// case OP_REMOVEXATTR: REMOVEXATTR4res opremovexattr;
/// */
<CODE ENDS>
<コード終了>
The caching behavior for extended attributes is similar to other file attributes such as ACLs and is affected by whether or not OPEN delegation has been granted to a client.
拡張属性のキャッシュ動作は、ACLなどの他のファイル属性と同様であり、OPEN委任がクライアントに付与されているかどうかに影響されます。
Xattrs obtained from, or sent to, the server may be cached and clients can use them to avoid subsequent GETXATTR requests, provided that the client can ensure that the cached value has not been subsequently modified by another client. Such assurance can be based on the client holding a delegation for the file in question or the client interrogating the change attribute to make sure that any cached value is still valid. Such caching may be read-only or write-through.
サーバーから取得または送信されたXattrsはキャッシュされ、クライアントは、キャッシュされた値が別のクライアントによって後で変更されていないことを確認できれば、後続のGETXATTR要求を回避するためにそれらを使用できます。このような保証は、問題のファイルの委任を保持しているクライアント、または変更属性に問い合わせてキャッシュされた値がまだ有効であることを確認するクライアントに基づくことができます。このようなキャッシングは、読み取り専用またはライトスルーの場合があります。
When a delegation is in effect, some operations by a second client to a delegated file will cause the server to recall the delegation through a callback. For individual operations, we describe, under IMPLEMENTATION, when such operations are required to effect a recall.
委任が有効な場合、委任されたファイルに対する2番目のクライアントによる一部の操作により、サーバーはコールバックを通じて委任を呼び出します。個々の操作については、「実装」で、リコールを実行するためにそのような操作が必要な場合について説明します。
The result of local caching is that the individual xattrs maintained on clients may not be up to date. Changes made in one order on the server may be seen in a different order on one client and in a third order on another client. In order to limit problems that may arise due to separate operations to obtain individual xattrs and other file attributes, a client should treat xattrs just like other file attributes with respect to caching as detailed in Section 10.6 of [RFC7530]. A client may validate its cached version of an xattr for a file by fetching the change attribute and assuming that if the change attribute has the same value as it did when the attributes were cached, then xattrs have not changed. If the client holds a delegation that ensures that the change attribute cannot be modified by another client, it can dispense with actual interrogation of the change attribute.
ローカルキャッシングの結果、クライアントで維持されている個々のxattrsが最新でない可能性があります。サーバーで1つの順序で行われた変更は、1つのクライアントでは別の順序で、別のクライアントでは3番目の順序で表示される場合があります。個別のxattrsと他のファイル属性を取得するための個別の操作によって発生する可能性のある問題を制限するために、クライアントは[RFC7530]のセクション10.6で詳述されているように、xattrをキャッシュに関して他のファイル属性と同様に扱う必要があります。クライアントは、変更属性をフェッチし、変更属性が属性がキャッシュされたときと同じ値である場合、xattrsは変更されていないと想定して、ファイルのxattrのキャッシュバージョンを検証できます。クライアントが、変更属性が別のクライアントによって変更されないようにする委任を保持している場合、変更属性の実際の問い合わせを省略できます。
When a client is changing xattrs of a file, it needs to determine whether there have been changes made to the file by other clients. It does this by using the change attribute as reported before and after the change operation (SETXATTR or REMOVEXATTR) in the associated change_info4 value returned for the operation. The server is able to communicate to the client whether the change_info4 data is provided atomically with respect to the change operation. If the change values are provided atomically, the client has a basis for determining, given proper care, whether other clients are modifying the file in question.
クライアントがファイルのxattrsを変更する場合、他のクライアントによってファイルに変更が加えられたかどうかを判別する必要があります。これは、変更操作（SETXATTRまたはREMOVEXATTR）の前後に報告された変更属性を使用して、その操作に対して返された関連するchange_info4値で行います。サーバーは、change_info4データが変更操作に関してアトミックに提供されるかどうかをクライアントに通信できます。変更値がアトミックに提供される場合、クライアントは、適切な注意を払って、他のクライアントが問題のファイルを変更しているかどうかを判断するための基礎を持ちます。
An effective way to enable the client to make this determination simply is for it to serialize all xattr changes made to a specific file. When this is done, and the server provides before and after values of the change attribute atomically, the client can simply compare the after value of the change attribute from one operation with the before value on the subsequent change operation modifying the file. When these are equal, the client is assured that no other client is modifying the file in question.
クライアントがこの決定を行えるようにする効果的な方法は、特定のファイルに対して行われたすべてのxattr変更をシリアル化することです。これが行われ、サーバーが変更属性の前後の値をアトミックに提供する場合、クライアントは、ある操作の変更属性の変更後の値を、ファイルを変更する後続の変更操作の変更前の値と単純に比較できます。これらが等しい場合、クライアントは、他のクライアントが問題のファイルを変更していないことが保証されます。
If the comparison indicates that the file was updated by another client, the xattr cache associated with the modified file is purged from the client. If the comparison indicates no modification, the xattr cache can be updated on the client to reflect the file operation, and the associated timeout can be extended. The post-operation change value needs to be saved as the basis for future change_info4 comparisons.
比較により、ファイルが別のクライアントによって更新されたことが示される場合、変更されたファイルに関連付けられているxattrキャッシュはクライアントから削除されます。比較により変更がないことが示された場合、ファイル操作を反映するためにクライアントでxattrキャッシュを更新でき、関連するタイムアウトを延長できます。操作後の変更値は、将来のchange_info4比較の基礎として保存する必要があります。
Xattr caching requires that the client revalidate xattr cache data by inspecting the change attribute of a file at the point when an xattr was cached. This requires that the server update the change attribute when xattrs are modified. For a client to use the change_info4 information appropriately and correctly, the server must report the pre- and post-operation change attribute values atomically. When the server is unable to report the before and after values atomically with respect to the xattr update operation, the server must indicate that fact in the change_info4 return value. When the information is not atomically reported, the client should not assume that other clients have not changed the xattrs.
Xattrキャッシュでは、クライアントがxattrがキャッシュされた時点でファイルの変更属性を検査して、xattrキャッシュデータを再検証する必要があります。これには、xattrsが変更されたときにサーバーが変更属性を更新する必要があります。クライアントがchange_info4情報を適切かつ正しく使用するには、サーバーは操作前および操作後の変更属性値をアトミックに報告する必要があります。サーバーがxattr更新操作に関して前の値と後の値をアトミックに報告できない場合、サーバーはその事実をchange_info4の戻り値で示す必要があります。情報がアトミックに報告されない場合、クライアントは、他のクライアントがxattrsを変更していないと想定しないでください。
The protocol does not provide support for write-back caching of xattrs. As such, all modifications to xattrs should be done by requests to the server. The server should perform such updates synchronously.
このプロトコルは、xattrsのライトバックキャッシュをサポートしていません。そのため、xattrsへのすべての変更は、サーバーへの要求によって行われる必要があります。サーバーは、このような更新を同期的に実行する必要があります。
Xattr operations, for the most part, function independent of operations related to file locking state. For example, xattrs can be interrogated and modified without a corresponding OPEN operation. The server does not need to check for locks that conflict with xattr access or modify operations. For example, another OPEN specified with OPEN4_SHARE_DENY_READ or OPEN4_SHARE_DENY_BOTH does not prevent access to or modification of xattrs. Note that the server MUST still verify that the client is allowed to perform the xattr operation on the basis of access permissions.
Xattr操作は、ほとんどの場合、ファイルのロック状態に関連する操作とは無関係に機能します。たとえば、xattrsは、対応するOPEN操作なしで照会および変更できます。サーバーは、xattrアクセスまたは変更操作と競合するロックをチェックする必要はありません。たとえば、OPEN4_SHARE_DENY_READまたはOPEN4_SHARE_DENY_BOTHで指定された別のOPENは、xattrsへのアクセスまたは変更を妨げません。サーバーは、クライアントがアクセス許可に基づいてxattr操作を実行できることを確認する必要があることに注意してください。
However, the presence of delegations may dictate how xattr operations interact with the state-related logic. Xattrs cannot be modified when a delegation for the corresponding file is held by another client. On the other hand, xattrs can be interrogated despite the holding of a write delegation by another client since updates are write-through to the server.
ただし、委任の存在によって、xattr操作が状態関連のロジックとどのように相互作用するかが決まる場合があります。対応するファイルの委任が別のクライアントによって保持されている場合、Xattrsは変更できません。一方、更新はサーバーへのライトスルーであるため、別のクライアントによる書き込み委任の保持にもかかわらず、xattrsに問い合わせることができます。
All xattr operations are sent to the metadata server, which is responsible for fetching data from and effecting necessary changes to persistent storage.
すべてのxattr操作はメタデータサーバーに送信されます。メタデータサーバーは、永続的なストレージからデータをフェッチし、永続的なストレージに必要な変更を行います。
Since xattrs are application data, security issues are exactly the same as those relating to the storing of file data and named attributes. Clients MUST NOT accord any system-interpreted semantics to xattrs, since their use is restricted to user-managed metadata only as explained in Section 5. Extended attributes are various sorts of application data, and the fact that the means of reference is slightly different in each case should not be considered security relevant. As such, the additions to the NFS protocol for supporting extended attributes do not alter the security considerations of the NFSv4 protocol [RFC7530].
xattrsはアプリケーションデータであるため、セキュリティの問題は、ファイルデータと名前付き属性の格納に関連するものとまったく同じです。クライアントは、システムが解釈するセマンティクスをxattrsに一致させてはなりません。その使用は、セクション5で説明されているユーザー管理のメタデータのみに制限されているためです。拡張属性はさまざまな種類のアプリケーションデータであり、参照方法がいずれの場合も、セキュリティ関連であると考えるべきではありません。そのため、拡張属性をサポートするためのNFSプロトコルへの追加は、NFSv4プロトコルのセキュリティに関する考慮事項を変更しません[RFC7530]。
The addition of xattr support to the NFSv4 protocol does not require any actions by IANA. This document limits xattr names to the user namespace, where application developers are allowed to define and use attributes as needed. Unlike named attributes, there is no namespace identifier associated with xattrs that may require registration.
NFSv4プロトコルへのxattrサポートの追加には、IANAによるアクションは必要ありません。このドキュメントでは、xattr名をユーザーネームスペースに制限しています。アプリケーション開発者は、必要に応じて属性を定義および使用できます。名前付き属性とは異なり、登録を必要とする可能性のあるxattrsに関連付けられている名前空間識別子はありません。
[LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents", Version 5.0, March 2015, <http://trustee.ietf.org/docs/ IETF-Trust-License-Policy.pdf>.
[法的] IETFトラスト、「IETFドキュメントに関連する法的規定」、バージョン5.0、2015年3月、<http://trustee.ietf.org/docs/ IETF-Trust-License-Policy.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 2006, <https://www.rfc-editor.org/info/rfc4506>.
[RFC4506] Eisler、M。、編、「XDR：外部データ表現標準」、STD 67、RFC 4506、DOI 10.17487 / RFC4506、2006年5月、<https://www.rfc-editor.org/info/rfc4506 >。
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, <https://www.rfc-editor.org/info/rfc5661>.
[RFC5661] Shepler、S.、Ed。、Eisler、M.、Ed。、and D. Noveck、Ed。、 "Network File System（NFS）Version 4 Minor Version 1 Protocol"、RFC 5661、DOI 10.17487 / RFC5661、 2010年1月、<https://www.rfc-editor.org/info/rfc5661>。
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC7530]ヘインズ、T。、エド。およびD. Noveck編、「Network File System（NFS）Version 4 Protocol」、RFC 7530、DOI 10.17487 / RFC7530、2015年3月、<https://www.rfc-editor.org/info/rfc7530>。
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, <https://www.rfc-editor.org/info/rfc7862>.
[RFC7862]ヘインズ、T。、「ネットワークファイルシステム（NFS）バージョン4マイナーバージョン2プロトコル」、RFC 7862、DOI 10.17487 / RFC7862、2016年11月、<https://www.rfc-editor.org/info/rfc7862 >。
[RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description", RFC 7863, DOI 10.17487/RFC7863, November 2016, <https://www.rfc-editor.org/info/rfc7863>.
[RFC7863]ヘインズ、T。、「ネットワークファイルシステム（NFS）バージョン4マイナーバージョン2外部データ表現標準（XDR）の説明」、RFC 7863、DOI 10.17487 / RFC7863、2016年11月、<https：//www.rfc- editor.org/info/rfc7863>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, <https://www.rfc-editor.org/info/rfc8178>.
[RFC8178] Noveck、D。、「Rules for NFSv4 Extensions and Minor Versions」、RFC 8178、DOI 10.17487 / RFC8178、2017年7月、<https://www.rfc-editor.org/info/rfc8178>。
[FreeBSD] FreeBSD, "FreeBSD Manual Pages - extattr", FreeBSD System Calls Manual, January 2008, <http://www.freebsd.org/ cgi/man.cgi?query=extattr&sektion=9>.
[FreeBSD] FreeBSD、「FreeBSDマニュアルページ-extattr」、FreeBSDシステムコールマニュアル、2008年1月、<http://www.freebsd.org/ cgi / man.cgi？query = extattr＆sektion = 9>。
[freedesktop] freedesktop, "Guidelines for extended attributes", May 2013, <http://www.freedesktop.org/wiki/ CommonExtendedAttributes>.
[freedesktop] freedesktop、「拡張属性のガイドライン」、2013年5月、<http://www.freedesktop.org/wiki/ CommonExtendedAttributes>。
[fsattr] Oracle, "fsattr - extended file attributes", Man Pages Section 5: Standards, Environments, and Macros, <http://docs.oracle.com/cd/E19253-01/816-5175/6mbba7f02>.
[fsattr] Oracle、「fsattr-拡張ファイル属性」、マニュアルページセクション5：標準、環境、およびマクロ、<http://docs.oracle.com/cd/E19253-01/816-5175/6mbba7f02>。
[KDE] Handa, V., "Extended Attributes Updates", August 2014, <http://vhanda.in/blog/2014/08/ extended-attributes-updates/>.
[KDE] Handa、V。、「Extended Attributes Updates」、2014年8月、<http://vhanda.in/blog/2014/08/extended-attributes-updates/>。
[Linux] The Linux man-pages project, "Linux Programmer's Manual: xattr(7)", Linux man pages: Section 7, September 2017, <http://man7.org/linux/man-pages/man7/xattr.7.html>.
[Linux] Linux man-pagesプロジェクト、「Linux Programmer's Manual：xattr（7）」、Linux manページ：セクション7、2017年9月、<http://man7.org/linux/man-pages/man7/xattr。 7.html>。
[Love] Love, R., "Linux System Programming: Talking Directly to the Kernel and C Library", O'Reilly Media, Inc., February 2009.
[Love] Love、R。、「Linuxシステムプログラミング：カーネルおよびCライブラリと直接対話する」、O'Reilly Media、Inc.、2009年2月。
[NTFS] Microsoft, "File Streams", <http://msdn.microsoft.com/en-us/library/windows/desktop/aa364404(v=vs.85).aspx>.
[NTFS] Microsoft、「ファイルストリーム」、<http://msdn.microsoft.com/en-us/library/windows/desktop/aa364404（v = vs.85）.aspx>。
[POSIX] The Open Group, "System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2016 Edition (HTML Version), ISBN 1937218812, September 2016, <http://pubs.opengroup.org/onlinepubs/9699919799/>.
[POSIX] The Open Group、「System Interfaces of the Open Group Base Specifications Issue 7」、IEEE Std 1003.1、2016 Edition（HTML Version）、ISBN 1937218812、2016年9月、<http://pubs.opengroup.org/onlinepubs/ 9699919799 />。
[Swift] The OpenStack Foundation Wiki, "Swift-on-File", July 2015, <https://wiki.openstack.org/wiki/Swiftonfile>.
[Swift] OpenStack Foundation Wiki、「Swift-on-File」、2015年7月、<https://wiki.openstack.org/wiki/Swiftonfile>。
Acknowledgments
謝辞
This document has attempted to capture the discussion on adding xattrs to the NFSv4 protocol from many participants on the IETF NFSv4 mailing list. Those who provided valuable input and comments on draft versions of this document include: Tom Haynes, Christoph Hellwig, Nico Williams, Dave Noveck, Benny Halevy, and Andreas Gruenbacher.
このドキュメントは、IETF NFSv4メーリングリストの多くの参加者から、NFSv4プロトコルにxattrsを追加することに関する議論を捉えようと試みました。このドキュメントのドラフト版について貴重な意見やコメントを提供してくれたのは、トムヘインズ、クリストフヘルウィグ、ニコウィリアムズ、デイブノベック、ベニーハーレビー、アンドレアスグルーエンバッハーです。
Authors' Addresses
著者のアドレス
Manoj Naik Nutanix 1740 Technology Drive, Suite 150 San Jose, CA 95110 United States of America
Manoj Naik Nutanix 1740 Technology Drive、Suite 150 San Jose、CA 95110アメリカ合衆国
Email: manoj.naik@nutanix.com
Marc Eshel IBM Almaden 650 Harry Road San Jose, CA 95120 United States of America
Marc Eshel IBMアルマデン650 Harry Road San Jose、CA 95120アメリカ合衆国
Phone: +1 408-927-1894
Email: eshel@us.ibm.com