rfc2086.txt (13925B)
1 2 3 4 5 6 7 Network Working Group J. Myers 8 Request for Comments: 2086 Carnegie Mellon 9 Category: Standards Track January 1997 10 11 12 IMAP4 ACL extension 13 14 Status of this Memo 15 16 This document specifies an Internet standards track protocol for the 17 Internet community, and requests discussion and suggestions for 18 improvements. Please refer to the current edition of the "Internet 19 Official Protocol Standards" (STD 1) for the standardization state 20 and status of this protocol. Distribution of this memo is unlimited. 21 22 1. Abstract 23 24 The ACL extension of the Internet Message Access Protocol [IMAP4] 25 permits access control lists to be manipulated through the IMAP 26 protocol. 27 28 Table of Contents 29 30 1. Abstract............................................... 1 31 2. Conventions Used in this Document...................... 1 32 3. Introduction and Overview.............................. 2 33 4. Commands............................................... 3 34 4.1. SETACL................................................. 3 35 4.2. DELETEACL.............................................. 4 36 4.3. GETACL................................................. 4 37 4.4. LISTRIGHTS............................................. 4 38 4.5. MYRIGHTS............................................... 5 39 5. Responses.............................................. 5 40 5.1. ACL.................................................... 5 41 5.2. LISTRIGHTS............................................. 6 42 5.3. MYRIGHTS............................................... 6 43 6. Formal Syntax.......................................... 6 44 7. References............................................. 7 45 8. Security Considerations................................ 7 46 9. Author's Address....................................... 8 47 48 2. Conventions Used in this Document 49 50 In examples, "C:" and "S:" indicate lines sent by the client and 51 server respectively. 52 53 54 55 56 57 58 Myers Standards Track [Page 1] 59 60 RFC 2086 ACL extension January 1997 61 62 63 3. Introduction and Overview 64 65 The ACL extension is present in any IMAP4 implementation which 66 returns "ACL" as one of the supported capabilities to the CAPABILITY 67 command. 68 69 An access control list is a set of <identifier,rights> pairs. 70 71 Identifier is a US-ASCII string. The identifier anyone is reserved 72 to refer to the universal identity (all authentications, including 73 anonymous). All user name strings accepted by the LOGIN or 74 AUTHENTICATE commands to authenticate to the IMAP server are reserved 75 as identifiers for the corresponding user. Identifiers starting with 76 a dash ("-") are reserved for "negative rights", described below. 77 All other identifier strings are interpreted in an implementation- 78 defined manner. 79 80 Rights is a string listing a (possibly empty) set of alphanumeric 81 characters, each character listing a set of operations which is being 82 controlled. Letters are reserved for ``standard'' rights, listed 83 below. The set of standard rights may only be extended by a 84 standards-track document. Digits are reserved for implementation or 85 site defined rights. The currently defined standard rights are: 86 87 l - lookup (mailbox is visible to LIST/LSUB commands) 88 r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, 89 SEARCH, COPY from mailbox) 90 s - keep seen/unseen information across sessions (STORE SEEN flag) 91 w - write (STORE flags other than SEEN and DELETED) 92 i - insert (perform APPEND, COPY into mailbox) 93 p - post (send mail to submission address for mailbox, 94 not enforced by IMAP4 itself) 95 c - create (CREATE new sub-mailboxes in any implementation-defined 96 hierarchy) 97 d - delete (STORE DELETED flag, perform EXPUNGE) 98 a - administer (perform SETACL) 99 100 An implementation may tie rights together or may force rights to 101 always or never be granted to particular identifiers. For example, 102 in an implementation that uses unix mode bits, the rights "wisd" are 103 tied, the "a" right is always granted to the owner of a mailbox and 104 is never granted to another user. If rights are tied in an 105 implementation, the implementation must be conservative in granting 106 rights in response to SETACL commands--unless all rights in a tied 107 set are specified, none of that set should be included in the ACL 108 entry for that identifier. A client may discover the set of rights 109 which may be granted to a given identifier in the ACL for a given 110 mailbox by using the LISTRIGHTS command. 111 112 113 114 Myers Standards Track [Page 2] 115 116 RFC 2086 ACL extension January 1997 117 118 119 It is possible for multiple identifiers in an access control list to 120 apply to a given user (or other authentication identity). For 121 example, an ACL may include rights to be granted to the identifier 122 matching the user, one or more implementation-defined identifiers 123 matching groups which include the user, and/or the identifier 124 "anyone". How these rights are combined to determine the user's 125 access is implementation-defined. An implementation may choose, for 126 example, to use the union of the rights granted to the applicable 127 identifiers. An implementation may instead choose, for example, to 128 only use those rights granted to the most specific identifier present 129 in the ACL. A client may determine the set of rights granted to the 130 logged-in user for a given mailbox by using the MYRIGHTS command. 131 132 When an identifier in an ACL starts with a dash ("-"), that indicates 133 that associated rights are to be removed from the identifier that is 134 prefixed by the dash. For example, if the identifier "-fred" is 135 granted the "w" right, that indicates that the "w" right is to be 136 removed from users matching the identifier "fred". Implementations 137 need not support having identifiers which start with a dash in ACLs. 138 139 4. Commands 140 141 4.1. SETACL 142 143 Arguments: mailbox name 144 authentication identifier 145 access right modification 146 147 Data: no specific data for this command 148 149 Result: OK - setacl completed 150 NO - setacl failure: can't set acl 151 BAD - command unknown or arguments invalid 152 153 The SETACL command changes the access control list on the 154 specified mailbox so that the specified identifier is granted 155 permissions as specified in the third argument. 156 157 The third argument is a string containing an optional plus ("+") 158 or minus ("-") prefix, followed by zero or more rights characters. 159 If the string starts with a plus, the following rights are added 160 to any existing rights for the identifier. If the string starts 161 with a minus, the following rights are removed from any existing 162 rights for the identifier. If the string does not start with a 163 plus or minus, the rights replace any existing rights for the 164 identifier. 165 166 167 168 169 170 Myers Standards Track [Page 3] 171 172 RFC 2086 ACL extension January 1997 173 174 175 4.2. DELETEACL 176 177 Arguments: mailbox name 178 authentication identifier 179 180 Data: no specific data for this command 181 182 Result: OK - deleteacl completed 183 NO - deleteacl failure: can't delete acl 184 BAD - command unknown or arguments invalid 185 186 The DELETEACL command removes any <identifier,rights> pair for the 187 specified identifier from the access control list for the specified 188 mailbox. 189 190 4.3. GETACL 191 192 Arguments: mailbox name 193 194 Data: untagged responses: ACL 195 196 Result: OK - getacl completed 197 NO - getacl failure: can't get acl 198 BAD - command unknown or arguments invalid 199 200 The GETACL command returns the access control list for mailbox in 201 an untagged ACL reply. 202 203 Example: C: A002 GETACL INBOX 204 S: * ACL INBOX Fred rwipslda 205 S: A002 OK Getacl complete 206 207 4.4. LISTRIGHTS 208 209 Arguments: mailbox name 210 authentication identifier 211 212 Data: untagged responses: LISTRIGHTS 213 214 Result: OK - listrights completed 215 NO - listrights failure: can't get rights list 216 BAD - command unknown or arguments invalid 217 218 The LISTRIGHTS command takes a mailbox name and an identifier and 219 returns information about what rights may be granted to the identifier 220 in the ACL for the mailbox. 221 222 223 224 225 226 Myers Standards Track [Page 4] 227 228 RFC 2086 ACL extension January 1997 229 230 231 Example: C: a001 LISTRIGHTS ~/Mail/saved smith 232 S: * LISTRIGHTS ~/Mail/saved smith la r swicd 233 S: a001 OK Listrights completed 234 235 236 C: a005 LISTRIGHTS archive.imap anyone 237 S: * LISTRIGHTS archive.imap anyone "" l r s w i p c d a 238 0 1 2 3 4 5 6 7 8 9 239 240 4.5. MYRIGHTS 241 242 Arguments: mailbox name 243 244 Data: untagged responses: MYRIGHTS 245 246 Result: OK - myrights completed 247 NO - myrights failure: can't get rights 248 BAD - command unknown or arguments invalid 249 250 The MYRIGHTS command returns the set of rights that the user has 251 to mailbox in an untagged MYRIGHTS reply. 252 253 Example: C: A003 MYRIGHTS INBOX 254 S: * MYRIGHTS INBOX rwipslda 255 S: A003 OK Myrights complete 256 257 5. Responses 258 259 5.1. ACL 260 261 Data: mailbox name 262 zero or more identifier rights pairs 263 264 The ACL response occurs as a result of a GETACL command. The first 265 string is the mailbox name for which this ACL applies. This is 266 followed by zero or more pairs of strings, each pair contains the 267 identifier for which the entry applies followed by the set of 268 rights that the identifier has. 269 270 271 272 273 274 275 276 277 278 279 280 281 282 Myers Standards Track [Page 5] 283 284 RFC 2086 ACL extension January 1997 285 286 287 5.2. LISTRIGHTS 288 289 Data: mailbox name 290 identifier 291 required rights 292 list of optional rights 293 294 The LISTRIGHTS response occurs as a result of a LISTRIGHTS 295 command. The first two strings are the mailbox name and identifier 296 for which this rights list applies. Following the identifier is a 297 string containing the (possibly empty) set of rights the 298 identifier will always be granted in the mailbox. 299 300 Following this are zero or more strings each containing a set of 301 rights the identifier may be granted in the mailbox. Rights 302 mentioned in the same string are tied together--either all must be 303 granted to the identifier in the mailbox or none may be granted. 304 305 The same right may not be listed more than once in the LISTRIGHTS 306 command. 307 308 5.3. MYRIGHTS 309 310 Data: mailbox name 311 rights 312 313 The MYRIGHTS response occurs as a result of a MYRIGHTS command. 314 The first string is the mailbox name for which these rights apply. 315 The second string is the set of rights that the client has. 316 317 6. Formal Syntax 318 319 The following syntax specification uses the augmented Backus-Naur 320 Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. 321 Non-terminals referenced but not defined below are as defined by 322 [IMAP4]. 323 324 Except as noted otherwise, all alphabetic characters are case- 325 insensitive. The use of upper or lower case characters to define 326 token strings is for editorial clarity only. Implementations MUST 327 accept these strings in a case-insensitive fashion. 328 329 330 331 332 333 334 335 336 337 338 Myers Standards Track [Page 6] 339 340 RFC 2086 ACL extension January 1997 341 342 343 acl_data ::= "ACL" SPACE mailbox *(SPACE identifier SPACE 344 rights) 345 346 deleteacl ::= "DELETEACL" SPACE mailbox SPACE identifier 347 348 getacl ::= "GETACL" SPACE mailbox 349 350 identifier ::= astring 351 352 listrights ::= "LISTRIGHTS" SPACE mailbox SPACE identifier 353 354 listrights_data ::= "LISTRIGHTS" SPACE mailbox SPACE identifier 355 SPACE rights *(SPACE rights) 356 357 mod_rights ::= astring 358 ;; +rights to add, -rights to remove 359 ;; rights to replace 360 361 myrights ::= "MYRIGHTS" SPACE mailbox 362 363 myrights_data ::= "MYRIGHTS" SPACE mailbox SPACE rights 364 365 rights ::= astring 366 367 setacl ::= "SETACL" SPACE mailbox SPACE identifier 368 SPACE mod_rights 369 370 7. References 371 372 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 373 RFC 1730, University of Washington, December 1994. 374 375 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 376 Messages", STD 11, RFC 822. 377 378 8. Security Considerations 379 380 An implementation must make sure the ACL commands themselves do not 381 give information about mailboxes with appropriately restricted ACL's. 382 For example, a GETACL command on a mailbox for which the user has 383 insufficient rights should not admit the mailbox exists, much less 384 return the mailbox's ACL. 385 386 387 388 389 390 391 392 393 394 Myers Standards Track [Page 7] 395 396 RFC 2086 ACL extension January 1997 397 398 399 9. Author's Address 400 401 John G. Myers 402 Carnegie-Mellon University 403 5000 Forbes Ave. 404 Pittsburgh PA, 15213-3890 405 406 Email: jgm+@cmu.edu 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 Myers Standards Track [Page 8] 451