Reviewed:  https://review.openstack.org/217260
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=d4409c0a046c6ce0e14e18c95efe2cd16cf120e8
Submitter: Jenkins
Branch:    master

commit d4409c0a046c6ce0e14e18c95efe2cd16cf120e8
Author: Samuel Merritt <email address hidden>
Date:   Tue Aug 11 09:10:13 2015 -0500

    Better scoping for tempurls, especially container tempurls
    
    It used to be that a GET of a tempurl referencing a large object would
    let you download that large object regardless of where its segments
    lived. However, this led to some violated user expectations around
    container tempurls.
    
    (Note on shorthand: all tempurls reference objects. However, "account
    tempurl" and "container tempurl" are shorthand meaning tempurls
    generated using a key on the account or container, respectively.)
    
    Let's say an application is given tempurl keys to a particular
    container, and it does all its work therein using those keys. The user
    expects that, if the application is compromised, then the attacker
    only gains access to the "compromised-container". However, with the old
    behavior, the attacker could read data from *any* container like so:
    
    1) Choose a "victim-container" to download
    
    2) Create PUT and GET tempurl for any object name within the
       "compromised-container". The object doesn't need to exist;
       we'll create it.
    
    3) Using the PUT tempurl, upload a DLO manifest with
       "X-Object-Manifest: /victim-container/"
    
    4) Using the GET tempurl, download the object created in step 3. The
       result will be the concatenation of all objects in the
       "victim-container".
    
    Step 3 need not be for all objects in the "victim-container"; for
    example, a value "X-Object-Manifest: /victim-container/abc" would only
    be the concatenation of all objects whose names begin with "abc". By
    probing for object names in this way, individual objects may be found
    and extracted.
    
    A similar bug would exist for manifests referencing other accounts
    except that neither the X-Object-Manifest (DLO) nor the JSON manifest
    document (SLO) have a way of specifying a different account.
    
    This change makes it so that a container tempurl only grants access to
    objects within its container, *including* large-object segments. This
    breaks backward compatibility for container tempurls that may have
    pointed to cross container *LO's, but (a) there are security
    implications, and (b) container tempurls are a relatively new feature.
    
    This works by having the tempurl middleware install an authorization
    callback ('swift.authorize' in the WSGI environment) that limits the
    scope of any requests to the account or container from which the key
    came.
    
    This requires swift.authorize to persist for both the manifest request
    and all segment requests; this is done by having the proxy server
    restore it to the WSGI environment prior to returning from __call__.
    
    [CVE-2015-5223]
    
    Co-Authored-By: Clay Gerrard <email address hidden>
    Co-Authored-By: Alistair Coles <email address hidden>
    Co-Authored-By: Christian Schwede <email address hidden>
    Co-Authored-By: Matthew Oliver <email address hidden>
    
    Change-Id: Ie6d52f7a07e87f6fec21ed8b0ec1d84be8b2b11c
    Closes-Bug: 1449212