idnits 2.17.1 draft-faibish-nfsv4-pnfs-access-permissions-check-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 267 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (October 20, 2009) is 5302 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'LEGAL' is defined on line 563, but no explicit reference was found in the text == Unused Reference: 'XDR' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'MPFS' is defined on line 591, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'LEGAL' Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 Working Group S. Faibish 3 Internet-Draft EMC Corporation 4 Intended status: draft D. Black 5 Expires: April 20, 2010 EMC Corporation 6 M. Eisler 7 NetApp 8 October 20, 2009 10 pNFS Access Permissions Check 11 draft-faibish-nfsv4-pnfs-access-permissions-check-01 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on April 20, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document describes an extension to the pNFS protocol addressing 50 a gap related to the access permission checks to data servers used by 51 the MDS in layouts sent to the clients. The draft addresses both the 52 client access permission checks as well as the MDS access permissions 53 to the data servers. The draft will address new errors related to 54 access permission denial to devices included in valid pNFS layouts. 55 The draft will also address the case when clients request direct NFS 56 access to the MDS and the MDS has no permission to access some of the 57 data servers included in valid layouts. 59 Table of Contents 61 1. Introduction...................................................3 62 1.1. Example...................................................4 63 1.2. Issues with the current pNFS protocol.....................5 64 1.2.1. Client access permission denial to SD................6 65 1.2.2. MDS access permission denial to SD...................6 66 1.2.3. Implied Requirement..................................7 67 2. Conventions used in this document..............................7 68 3. Description of the proposed approaches to solution.............7 69 3.1. Defining the opaque fields of LAYOUTRETURN................8 70 3.1.1. ARGUMENT.............................................8 71 3.1.2. RESULT...............................................9 72 3.1.3. Description..........................................9 73 3.2. Implementation using a new layoutreturn_type4.............9 74 3.2.1. ARGUMENT.............................................9 75 3.2.2. RESULT..............................................10 76 3.2.3. New LAYOUTRETURN type description...................10 77 4. Reporting the permission denial...............................11 78 4.1. Permission denied to client at mount time................11 79 4.2. Permission denied to the client at I/O time..............12 80 4.3. Permission denied to MDS server at I/O time..............12 81 5. Security Considerations.......................................12 82 6. IANA Considerations...........................................13 83 7. Conclusions...................................................13 84 8. References....................................................13 85 8.1. Normative References.....................................13 86 8.2. Informative References...................................14 87 9. Acknowledgments...............................................14 88 Authors' Addresses...............................................15 90 1. Introduction 92 Figure 1 shows the overall architecture of a Parallel NFS (pNFS) 93 system: 95 +-----------+ 96 |+-----------+ +-----------+ 97 ||+-----------+ | | 98 ||| | NFSv4.1 + pNFS | | 99 +|| Clients |<------------------------------>| MDS | 100 +| | | | 101 +-----------+ | | 102 ||| +-----------+ 103 ||| | 104 ||| | 105 ||| Storage +-----------+ | 106 ||| Protocol |+-----------+ | 107 ||+----------------||+-----------+ Control | 108 |+-----------------||| | Protocol | 109 +------------------+|| Storage |------------+ 110 +| Devices | 111 +-----------+ 113 Figure 1 pNFS Architecture 115 There is a possible gap in the pNFS protocol regarding permissions of 116 access to storage devices in the cases of a client that has no 117 permission to access a storage device (SD) included in a valid layout 118 sent by the MDS server. Some consider this gap an implementation 119 detail but the permission denials can defeat the performance 120 scalability value of pNFS and allow for unreported errors. From the 121 pNFS protocol perspective there is no error mechanism to inform a 122 system administrator that a client doesn't have the correct access 123 permissions to a storage device either at mount time or at I/O time. 124 This is also the case with the MDS that doesn't have access 125 permission to some storage devices and it is asked by a client to 126 perform I/O to the device on behalf of the client. In this document 127 storage devices mean data servers and storage severs which could 128 refer to file, block or object storage. 130 In the case of the block layout if the MDS doesn't have the correct 131 permissions to access the storage devices/LUNs it will not succeed in 132 mounting the pNFS file system using those devices. It follows that 133 the MDS will not allow a client to mount that file system and an 134 error will presumably be logged by the MDS server. If the MDS can 135 access all the storage devices/LUNs but the client doesn't have the 136 access permission to some storage devices/LUNs, at mount time the 137 client may mount the file system using NFSV4.1 without pNFS support 138 (fallback to NFS). This failure to mount as a pNFS file system 139 cannot be communicated to the server because there are not protocol 140 messages defined which convey this failure. 142 This is true for file and object layout pNFS clients regardless of 143 the whether the MDS has permissions to access the storage devices or 144 not. On the other hand, for the file and object layouts there is no 145 similar error mechanism to report the case when the client or the 146 server cannot access a storage device and there is no CB for access 147 permission check. The only fallback is a request for re-direct by the 148 MDS server as storage device is inaccessible assuming that the MDS 149 server has access to the storage device and it can serve the I/O to 150 the client still without logging an error at least not at mount time. 151 This assumption is weaker than in the case of the block layout that 152 cannot allow to mount a FSID to which it has no access permission. 154 1.1. Example 156 A typical use case is when a new storage device is added and all the 157 pNFS clients (1000s of them) lack access permission to the new 158 storage device. From this time on all the I/Os to the new storage 159 device will be served by the MDS server creating a performance and 160 scalability bottleneck that may be difficult to detect. 162 A better approach to this issue is to report the access failure 163 before the client attempts to issue any I/Os to the MDS server. This 164 makes the problem explicit, rather than the forcing the MDS, or a 165 system administrator to intuit or otherwise diagnose the performance 166 problem caused by client I/O using NFS path and not using the pNFS 167 layout. In the current pNFS protocol a client cannot detect this 168 situation at mount time in cases of complex mountpoint structures and 169 we can perhaps only address the error for the root/top of the mount 170 structure assuming we are only referring to pNFS capable clients. See 171 section 1.2.1 for a detailed example. 173 The intention of this draft is to introduce a new access permission 174 check and error access permission denial report mechanism at both 175 server and client to address the above issues. 177 One of the problems may be the fact that there is no mention in the 178 pNFS spec to address the data protocol between MDS and storage 179 devices, except for the block layout driver in which case the MDS 180 cannot itself mount a pNFS file system due to access permission 181 issue. In order for the MDS server to export a filesystem as NFSV4.1 182 filesystem for pNFS clients access it is mandatory for the MDS to 183 have access permission to all the storage devices/LUNs for that 184 filesystem as a pre-condition for the mount. In the case that there 185 is any access permission issue the filesystem cannot be mounted by 186 the MDS and an error is sent to the MDS server log. 188 On the other hand for file and object pNFS layout MDS servers there 189 is no requirement in the spec to check access permission to all the 190 storage devices even when the NFSV4.1 filesystem is exported to the 191 pNFS clients. In fact an MDS that accesses the storage devices is 192 considered an unhealthy pNFS server except for the case when a pNFS 193 client falls back to NFS and requests the MDS server to perform an 194 I/O on its behalf. At that time the MDS must access the storage 195 server in order to perform the I/O. It is then possible that the MDS 196 I/O to the storage device fails due to an access permission denial. 197 In this case the MDS will send a error to the client and the client 198 I/O will fail. 200 There is no error reporting mechanism in the pNFS protocol for this 201 type of error. Even if we correct the access permission issue the 202 introduction of a new error reporting mechanism at I/O time for both 203 server and client can be problematic as it may be too chatty. We 204 propose to introduce a new error case but leave the error reporting 205 mechanism at I/O time OPTIONAL or an optimization to the latitude of 206 the server and client implementation. 208 Although the change to the protocol is delicate, logging some kind of 209 warning at the client might be appropriate as an implementation 210 option on the client to reduce chattiness. 212 1.2. Issues with the current pNFS protocol 214 Scenario of Interest: Client expects to be able to use pNFS (e.g., 215 use -pnfs switch to mount command, or similar), but one or more 216 devices are inaccessible. This discussion does not apply to a client 217 that doesn't care (e.g., uses pNFS to optimize if available, but is 218 ok if all of its access is via the main NFS server). 220 Desired client behavior: Client gets the entire device list for a 221 mount point from server and checks it as part of the mount operation 222 (or at whatever point it first realizes that it expects to use pNFS). 224 Missing piece of protocol: Client has no obvious way to report an 225 inaccessible device to the server. 227 1.2.1. Client access permission denial to SD 229 A client doesn't communicate to the MDS server that the client's 230 access to a storage device is denied as a result of an access 231 permission issue. When the pNFS server grants a layout to the client, 232 it assumes the client can access the storage devices (files, luns, or 233 objects). The server cannot check this because the server cannot 234 issue I/Os via the client and because connectivity is not transitive 235 - the client may have good network connectivity to the MDS, the MDS 236 may have good storage connectivity to the storage devices, but 237 something in the storage network prevents the client from talking to 238 one or more of the storage devices. This could be a network mis- 239 configuration or failure, and it's a possible scenario for all pNFS 240 layout types. 242 The access permission problem cannot be reported at mount time for a 243 number of reasons. First, the MDS pNFS server doesn't know that the 244 client can even mount with pNFS support. Second, the MDS NFS server 245 doesn't know that the client is mounting the NFS filesystem (there is 246 no separate mount protocol in NFSv4). Third, the MDS server cannot 247 know if the client mounts say, "/", and the file systems below "/" 248 have pNFS capabilities, but refer to different storage devices. Or 249 the client mounts say "/a/b/c/d", and d is in a pNFS capable volume. 250 But the client is going actually do its I/O to "e/f/g/h/i/j/k", and k 251 is either no pNFS capable, or it is, but uses a storage device that 252 differs from d. 254 1.2.2. MDS access permission denial to SD 256 The current pNFS server protocol doesn't mandatory require to access 257 the storage devices and there is only a control protocol (Fig. 1) 258 between the MDS and the storage devices but there is no specific data 259 access protocol between the MDS and the SDs. Although the MDS doesn't 260 check permissions it is assumed that at the configuration is correct 261 when the storage devices are initially configured and the pNFS 262 filesystem is mounted on the MDS server. It is possible that the 263 administrator checks the MDS access permission to all the SD during 264 the configuration. The problem may not exist at the time of the 265 initial mount of the pNFS filesystem but can surface when a new SD is 266 added to the pool of SDs. If the MDS tries to do successful I/Os to 267 the new added SD before including it in the layout to pNFS clients 268 will avoid this set of problems. The pNFS specification does not 269 address the data access protocol between the MDS and the storage 270 devices. 272 1.2.3. Implied Requirement 274 Metadata server SHOULD NOT use devices in pNFS layouts that are not 275 accessible to the MDS (or to clients if the MDS has any means of 276 determining this). 278 2. Conventions used in this document 280 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 281 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 282 document are to be interpreted as described in RFC-2119 [RFC2119]. 284 3. Description of the proposed approaches to solution 286 There are several possible solutions. The first is to implement a 287 new operation, LAYOUTRETURN4x that returns layouts to the MDS along 288 with error information. Clients that receive an NFS4ERR_NOTSUPP 289 error SHOULD mark the server as not supporting this operation and use 290 LAYOUTRETURN instead. 292 Another possible approach to address the gap in the protocol is to 293 make use of the opaque field available in LAYOUTRETURN. One could 294 define this type for all layout types. In the case that the pNFS 295 client has a valid layout on a file but cannot perform I/O to a SD 296 due to access permission denial, the client will fall back the I/O to 297 the MDS NFS server. Before the client sends the I/O to the NFS server 298 it will send a LAYOUTRETURN command for the purpose of avoiding 299 unnecessary MDS CB_LAYOUTRECALL operations in the future. The client 300 will send the LAYOUTRETURN operation for the layouts corresponding to 301 the inaccessible SD and include an error reporting that the reason 302 for the fall back to the NFS server is an access permission denial to 303 the specific deviceid4. The client may return disjoint regions of the 304 file by using multiple LAYOUTRETURN operations within a single 305 COMPOUND operation. The client will include NFS4ERR_DEVICE_PERM_DENY 306 in the new LAYOUTRETURN operation. 308 A third approach is to introduce a new LAYOUTRETURN type at FSID 309 scope such as LAYOUT4_RET_REC_FSID_NO_ACCESS, i.e., return all 310 layouts for this FSID and tell the server that the reason for the 311 return is a connectivity issue. In order to differentiate the 312 permission issue from a real connectivity issue the solution will 313 require the client to do two LAYOUTRETURN operations to deal with 314 servers that don't understand the new type. The two LAYOUTRETURN 315 operations happen once per client using 316 LAYOUT4_RET_REC_FSID_NO_ACCESS and only in an error case followed by 317 a second operation for "FSID" in case the first one wasn't 318 understood. 320 3.1. Defining the opaque fields of LAYOUTRETURN 322 3.1.1. ARGUMENT 324 When the LAYOUTRETURN operation specifies a LAYOUTRETURN4_FILE_return 325 type, then the layoutreturn_file4 data structure specifies the region 326 of the file layout that is no longer needed by the client. For each 327 layout type we define the opaque lrf_body so that it can communicate 328 an error code to the server as well as the deviceid4 which 329 encountered the error. This has already been defined for the object 330 layout type [draft-ietf-nfsv4-pnfs-obj-12]. 332 For the file layout we define the opaque body as follows: 334 struct nfsv4_1_file_layoutreturn4 { 335 deviceid4 lrf_deviceid; 336 nfsstat4 lrf_status; 337 }; 339 An MDS server should check the length of the lrf_body. If the length 340 is zero, then the client has not communicated additional information 341 with the layout return. This will generally be the case when a file 342 is closed, or in response to a CB_LAYOUTRECALL operation. 344 For the block layout type, we similarly define the block specific 345 structure as: 347 struct pnfs_block_layoutreturn4 { 348 deviceid4 lrf_deviceid; 349 nfsstat4 lrf_status; 350 }; 352 The alternative, which is more complex is to make the status (error) 353 and deviceid4 common to all LAYOUTRETURN operations, but do so by 354 adding a new operation or a new return 355 type(LAYOUT4_RET_REC_FILE_ERROR) 357 struct layoutreturn_file_error4 { 358 offset4 lrf_offset; 359 length4 lrf_length; 360 stateid4 lrf_stateid; 361 deviceid4 lrf_deviceid; 362 nfsstat4 lrf_status; 363 /* layouttype4 specific data */ 364 opaque lrf_body<>; 365 }; 367 3.1.2. RESULT 369 The LAYOUTRETURN4res remains unchanged. 371 3.1.3. Description 373 This solution will add a new error case to LAYOUTRETURN. The 374 implementation will use LAYOUTRETURN when FSID is sent to the client. 375 When the client fails an I/O as a result of access permission denial 376 it will send a LAYOUTRETURN operation to the MDS server with new 377 error NFS4ERR_DEVICE_PERM_DENY specifying the deviceid4 with 378 permission denial. 380 When the server receives this error it can OPTIONALLY log an error to 381 the syslog and perform an access performance check to the SD 382 expecting that the client will fall back the I/O to the MDS. If the 383 permission check of the server fails the NFS4ERR_DEVICE_PERM_DENY 384 will be sent to the syslog. 386 3.2. Implementation using a new layoutreturn_type4 388 In this section we will define the use case addressed by this 389 implementation. 391 3.2.1. ARGUMENT 393 /* Constants used for new LAYOUTRETURN and CB_LAYOUTRECALL */ 394 const LAYOUT4_RET_REC_FILE = 1; 395 const LAYOUT4_RET_REC_FSID = 2; 396 const LAYOUT4_RET_REC_ALL = 3; 397 const LAYOUT4_RET_REC_DEVICE = 4; 399 enum layoutreturn_type4 { 400 LAYOUTRETURN4_DEVICE = LAYOUT4_RET_REC_DEVICE_NO_ACCESS, 401 LAYOUTRETURN4_FILE = LAYOUT4_RET_REC_FILE, 402 LAYOUTRETURN4_FSID = LAYOUT4_RET_REC_FSID, 403 LAYOUTRETURN4_ALL = LAYOUT4_RET_REC_ALL 404 }; 405 struct layoutreturn_device4 { 406 offset4 lrf_offset; 407 length4 lrf_length; 408 stateid4 lrf_stateid; 409 deviceid4 lrf_deviceid; 410 nfsstat4 lrf_status; 411 /* layouttype4 specific data */ 412 opaque lrf_body<>; 413 }; 415 union layoutreturn4 switch(layoutreturn_type4 lr_returntype) { 416 case LAYOUTRETURN4_DEVICE: 417 layoutreturn_device4 lr_layout; 418 default: void; 419 }; 421 3.2.2. RESULT 423 union LAYOUTRETURN4res switch (nfsstat4 lorr_status) { 424 case NFS4_OK: 425 layoutreturn_stateid lorr_stateid; 426 default: 427 void; 428 }; 429 3.2.3. New LAYOUTRETURN type description 431 We will use a new LAYOUTRETURN layoutreturn_type4, let's call it 432 LAYOUT4_RET_REC_DEVICE_NO_ACCESS, in which case the client returns 433 all layouts for this DEVICE and OPTIONAL for the FSID and tell the 434 server that the reason for the return is a connectivity issue. The 435 same stateid may be used or in order to report a new error client 436 will force a new stateid. We will also add the operation to report a 437 new error NFS4ERR_DEVICE_PERM_DENY. 439 To address the backward compatibility may require a client to do two 440 layout return operations to deal with servers that don't understand 441 the new layoutreturn_type4. If the server doesn't understand the new 442 layoutreturn_type4, then the server will come back with an error 443 code. The client needs to do a FSID return and remember that this 444 server doesn't understand the new return type. This assumes that the 445 client is sufficient disrupted by the connectivity problem to the 446 point it decided to drop all layouts for the filesystem (FSID), which 447 matches the failure case of client data server access permission 448 deny. Alternatively when the server receives a new stateid it will 449 check the error or issue an CB_LAYOUTRECALL to get the error. 451 4. Reporting the permission denial 453 4.1. Permission denied to client at mount time 455 The most suitable time for the client reporting the permission denial 456 by a data server is at the mount time. This would be the preferred 457 way to address the issue but it is not possible with the current 458 protocol for several reasons: If the server initiates the request, 459 MDS doesn't know if the client wants to use pNFS or NFS. If the 460 client is the initiator of the error the is mounting the pNFS 461 filesystem knowing that it will use pNFS for access the client 462 doesn't specifically request pNFS. 464 The solution will be to use a special tag -pnfs or a switch to 465 mount/syscall. To the latest issue the client cannot explicitly 466 request pNFS as it needs first to discover that the server is 467 supporting pNFS. In order to address this issue the client needs to 468 send a request at mount time to the server as part of the initial 469 handshake. There is no reportable error of the client to cope with 470 this currently. 472 The client makes a file access and it finds that the NFS server is 473 pNFS capable it will request a LAYOUTGET command and if the NFS 474 server doesn't accept and returns an error the client will request 475 access using plain NFS. The client will decide if this is an error or 476 not. In the case that the LAYOUTGET command succeeded the client may 477 still ask the MDS to deliver the I/O. So, inherently the client has 478 to query the MDS access permissions to all the DS that are used in 479 the layout send to the client before putting the device into a 480 layout. The pNFS protocol doesn't require the MDS to check access 481 permission to the devices that are included in the layout. It is 482 assumed that the MDS has permission access to all the devices it 483 includes in the layout without any checks. 485 If the MDS doesn't know if it has access or not it shouldn't put that 486 device in the layout granted to clients to prevent cases when the 487 client ask the I/O using plain NFS from the MDS. If the MDS doesn't 488 have permission access to a data server it will send an error to the 489 client and the I/O will fail. Based on the above behavior the best 490 time to check is at the time when the initial configuration of the 491 pNFS filesystem is done. Currently the pNFS spec states that a client 492 can write through or read from the MDS, whether it has a layout or 493 not or it does not support pNFS assuming that the MDS has permission 494 access to all the data servers. We propose to make this implicit 495 recommendation explicit. 497 4.2. Permission denied to the client at I/O time 499 In this case when the pNFS capable client receives a valid layout 500 from the pNFS capable MDS server and due to access permission denial 501 to some devices cannot write to the storage devices, it will fall 502 back to the NFS server for the I/O. There is no error logged by the 503 client nor sent back to the MDS server mentioning the reason for the 504 fallback. As a result there is no way to fix the configuration 505 problem until the client unmounts the pNFS filesystem. And 506 potentially if there is no permission check at mount time even the 507 remount will not detect the problem. Moreover as the MDS server never 508 checks access permission to the storage devices the MDS will not be 509 able to perform the I/O unless the MDS is also a storage device 510 itself, in which case the I/O will fail without any error mentioning 511 permission denial. One option is for the MDS to send a LAYOUTRETURN 512 with FSID_PERM_CHECK in the case when the a pNFS client request the 513 MDS to write an I/O to one of the devices from a layout sent to the 514 client by the MDS the MDS will check the error and send a CB request 515 for FSID_PERM_CHECK. 517 4.3. Permission denied to MDS server at I/O time 519 In case when the client holding a valid layout requests the NFS 520 server to execute the I/O the MDS will have to access the data 521 server/device that the client requested to write to and gets an 522 access permission denial from the storage device, the MDS cannot 523 perform the I/O and will return an error to the client. In this case 524 the client I/O will fail indefinitely and there no error information 525 about the reason of the failure related to permission denial to data 526 servers. The client has no means to communicate to the server the 527 permission denial as there is no check and error case. To address 528 this case a new error code will be added to the LAYOUTRETURN call 529 mentioning DEVICE_PERM_DENY and the MDS will send an error to the 530 client NFS4ERR_PERM_DENY. An additional option is to send a CB to the 531 client requesting permission access check and on failure the MDS will 532 log an error NFS4ERR_DEVICE_UNACCESSIBLE to inform the admin to 533 correct the problem. On receiving the permission check the client 534 will send the DS a GETDEVICEINFO and report NFS4ERR_DEVICE_PERM_DENY 535 to the MDS server. 537 5. Security Considerations 539 All control operations from the MDS to the storage devices, including 540 any operations required for access permission checks in order to 541 detect permission denials to the MDS and the pNFS client, should be 542 authenticated in order to address cases when the access permission is 543 denied to the client by the administrator. It is expected that the 544 permission denial to a certain data server to a certain client will 545 be known to the MDS by configuration. This will be implemented for 546 all the pNFS layout types. 548 6. IANA Considerations 550 There are no IANA considerations in this document beyond pNFS IANA 551 Considerations are covered in [NFSV4.1]. 553 7. Conclusions 555 This draft specifies additions to the pNFS protocol addressing access 556 permission checks of the client and MDS server to storage devices 557 used in pNFS layouts for all layout types. 559 8. References 561 8.1. Normative References 563 [LEGAL] IETF Trust, "Legal Provisions Relating to IETF 564 Documents",URL http://trustee.ietf.org/docs/IETF-Trust- 565 License-Policy.pdf, November 2008. 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, March 1997. 570 [NFSV4.1] Shepler, S., Eisler, M., and Noveck, D. ed., "NFSv4 Minor 571 Version 1", RFC [[RFC Editor: please insert NFSv4 Minor 572 Version 1 RFC number]], [[RFC Editor: please insert NFSv4 573 Minor Version 1 RFC month]] [[RFC Editor: please insert 574 NFSv4 Minor Version 1 year]. 575 . 578 [draft-ietf-nfsv4-pnfs-block-12] 579 Black, D., Glasgow, J., Fridella, S., "pNFS Block/Volume 580 Layout". 582 [draft-ietf-nfsv4-pnfs-obj-12] 583 Halevy, B., Welch, B., Zelenka, J., "Object-based pNFS 584 Operations" 586 [XDR] Eisler, M., "XDR: External Data Representation Standard", 587 STD 67, RFC 4506, May 2006. 589 8.2. Informative References 591 [MPFS] EMC Corporation, "EMC Celerra Multi-Path File System", EMC 592 Data Sheet, available at: 593 http://www.emc.com/collateral/software/data-sheet/h2006- 594 celerra-mpfs-mpfsi.pdf 595 link checked 16 October 2009 597 9. Acknowledgments 599 This draft includes ideas from discussions with the authors of the 600 different pNFS layouts Jason Glasgow and Benny Halevy as well as pNFS 601 maintainer of Linux kernel including Bruce Fields. 603 This document was prepared using 2-Word-v2.0.template.dot. 605 Authors' Addresses 607 Sorin Faibish (editor) 608 EMC Corporation 609 32 Coslin Drive 610 Southboro, MA 01772 611 US 613 Phone: +1 (508) 305-8545 614 Email: sfaibish@emc.com 616 David L. Black 617 EMC Corporation 618 176 South Street 619 Hopkinton, MA 01748 620 US 622 Phone: +1 (508) 293-7953 623 Email: black_david@emc.com 625 Michael Eisler 626 NetApp 627 5765 Chase Point Circle 628 Colorado Springs, CO 80919 629 US 631 Phone: +1 (719) 599 8759 632 Email: mike@eisler.com