Bug 1041590

Summary: [RFE][swift]: Object ACLs support
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/swift/+spec/object-acls
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_new
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:23:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 18:07:40 UTC 
Cloned from launchpad blueprint https://blueprints.launchpad.net/swift/+spec/object-acls.

Description:

Evaluate what (if any) can be offered as Object ACLs on top of the container ACLs 
Thoughts coming up from the summit:
1. Check Container ACLs first, if ok, and if object ACLs exists, also check object ACLs

2. Consider implications of checking Object ACLs at the Object Server (using auth middleware at the object server)
     Note this means that each object server checks the ACLs individually and that we check later in the game. 
     Consider offering read ACLs but without write ACLs, to avoid cases in which object server are unaligned leading to undefined states.

3. Consider alternative to 2, checking  the ACLs at the proxy after the call have been made - this works for GET but not for modify (DELETE/PUT/POST). 


Specification URL (additional information):

None