OpenStack Object Storage (swift)

Unable to publically access an object with X-Object-Manifest reference

Bug #1075931 reported by Primoz Kolaric
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
Invalid
Undecided
Unassigned

Bug Description

I have two containers
container1 that holds an object named 'object1'
and
container2 that has an object named 'objectMF' that's actually an empty object with X-Object-Manifest that points to container1/object1

both containers have Read ACL: .r:*

I can publically access container1/object1, but can not publically access container2/objectMF (401 Unauthorized)
If i do authenticated GET, everything is ok.

Revision history for this message
Primoz Kolaric (primoz-kolaric) wrote :

If i add .rlistings ACL to the container1 (the one that actually holds the object) i can access that object through container2/objectMF.
But with that i allow listing of container1 objects to the public.

Revision history for this message
Samuel Merritt (torgomatic) wrote :

This behavior is intentional.

Imagine you've got a public container named "publiccon" with .r:* but not .rlistings, and it's full of files named with unguessable names. If you give someone a filename, they can download it, but they can't just guess the filenames.

Now imagine someone makes a manifest with "X-Object-Manifest: publiccon/". A GET to that manifest will get a response with the data of all the files in publiccon, even those whose filenames you haven't given out. Yes, it's all one jumbled-up bytestream, but depending on what the files are, it can be teased apart.

If you want this to work, add .rlistings to the ACL on the segments container.

Changed in swift:
status: New → Invalid
Revision history for this message
Primoz Kolaric (primoz-kolaric) wrote :

But if i only have 1:1 mapping from container2 to container1 files, the .rlistings on container1 is unnecessary and just exposes container1 listing.

Revision history for this message
Samuel Merritt (torgomatic) wrote :

True, but in other use cases (like the one I described), allowing the request to succeed without .rlistings is an information leak.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.