1 / 9

ACL draft Issues from IESG

ACL draft Issues from IESG. Basic MUST be over SSL/TLS DELETE not mapped to specific permission Model is excessively complex Too much flexibility, too many options Humans will err Clients will help humans err. Complexity: ACE Combination.

scott
Download Presentation

ACL draft Issues from IESG

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ACL draft Issues from IESG • Basic MUST be over SSL/TLS • DELETE not mapped to specific permission • Model is excessively complex • Too much flexibility, too many options • Humans will err • Clients will help humans err

  2. Complexity: ACE Combination • Note that each server may only advertise one of three ace combination models. • DAV:ace-combination • DAV:first-match • DAV:all-grant-before-any-deny • DAV:specific-deny-overrides-grant • Can we map all three of these to one canonical? • Then as long as the server does mapping right, security is improved (only one source of bugs).

  3. Complexity:ACE ordering • Note that a server must advertise either no ordering, or deny-before-grant ordering • DAV:ace-ordering • DAV:deny-before-grant • Can we cut this? Can servers that internally require deny to be “before” grant do reordering themselves?

  4. Complexity: Allowed ACE, Required Principals • Server may advertise limitations on the number/type of ACEs allowed internally (section 6.3) • Deny ACEs • Inverted ACEs • Only one per principal • Server may advertise what ACEs must exist (section 6.4) • This shouldn’t make modeling permissions harder • Client could ignore these and attempt to set the ACL improperly, but would get error

  5. Complexity: Optional errors • DAV:recognized-principal • Server MUST recognize the principal? • DAV:no-ace-conflict • Server MUST prevent conflicts? • Recommend more specificity on whether preconditions MUST or MAY be met.

  6. Privileges • Specific list of Privileges • Try to meet RFC3010 list? • Extensibility is a most – we can’t limit ACEs to a fixed list

  7. If header simplification • Proposal • Existing header: too complicated to determine which assertions are checked and against which resource • Require all assertions be evaluated, because “resources affected by” is too vague • Untagged assertions apply only to request-URI • Issues from list • Does this mean we need a lock model? • Do we clarify which operations require which locks? • Do we allow clients to submit locks in non-conditional headers? • Basic design principle: make implementations “fix up”, or

  8. New headers • New “Locktokens-Used” request header • Holds comma-separated lock tokens (no etags) • Can apply to any resource • Never cause the request to fail • New “Locktokens-No-Match” header • Holds comma-separated lock tokens that are expired, invalid, or didn’t match any resource’s locks • Allows server to correct client’s view of lock state • Also confirms that the server understands the Locktokens-Used header.

  9. Quota draft • Redefine quota-bytes and space-used-bytes • Quota  max. storage available to the user in area of the namespace in which the collection is allocated • Space used  current storage allocated to the user in this partition • Change names to use ‘octets’ rather than ‘bytes’

More Related