Possibility for data leakage when setting the same version location on separate containers

Bug #1138531 reported by Jasdeep Singh Hundal
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
python-swiftclient
In Progress
Wishlist
Elvis Teixeira

Bug Description

If you assign two containers to be versioned to the same container, you can get a leak where deleted objects in one container can be replaced by an old version of an object of the same name from the second container. Pretty sure this is not desireable behavior since this allows someone's versioned data to be lost by being moved to another container.

description: updated
Revision history for this message
Chmouel Boudjnah (chmouel) wrote : Re: [Bug 1138531] [NEW] Data leakage when setting the same version location on separate containers

Well if you have given this user access to this container (by the mean
of ACL i suppose) you should expect he can access all the data there.

Revision history for this message
Jasdeep Singh Hundal (jasdeep-hundal) wrote : Re: Data leakage when setting the same version location on separate containers

This is true, but at the very least, it'll be pretty surprising to see data you never put in a container show up in yours/somehow lose your versioned data to a different container. Granted this is undefined behavior right now...

description: updated
summary: - Data leakage when setting the same version location on separate
- containers
+ Possibility for data leakage when setting the same version location on
+ separate containers
Revision history for this message
Kun Huang (academicgareth) wrote :

I think if we can change .../object into account/container/object, it well be fixed.
I'm not sure. I'm checking it.

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

The place to fix this is in the client, IMHO. The client should set X-Container-Meta-Versions-For: somecontainer (or whatever header you want to use) when it turns on versioning, and if there's already one present, it should warn the user or abort the operation or something.

affects: swift → python-swiftclient
Changed in python-swiftclient:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Jasdeep Singh Hundal (jasdeep-hundal) wrote :

Moreso opened this ticket for clarification, but fixing it with a X-Container-Meta-Versions-For header precludes the use of one versioning container for a variety of other containers (may be a valid use case for having all object backups to one container?). I'd prefer labeling previous versions with their account/container, with the migration path being defaulting to the old behavior for versions w/o the extra label.

Revision history for this message
Kun Huang (academicgareth) wrote :

sam,
The header is "X-Versions-Location". And the api own doesn't support such warning, which in swift codes.

Jasdeep,
I agree with using "account/container", and some codes maybe want to implement it but seems failed.
And I think the version container (contains versioned data) should store data as "account/container/fffobject/timestamp", which is more readable and fix this bug.

Changed in python-swiftclient:
assignee: nobody → Kun Huang (academicgareth)
assignee: Kun Huang (academicgareth) → nobody
Changed in python-swiftclient:
assignee: nobody → Elvis Teixeira (elvis-teixeira)
Revision history for this message
Elvis Teixeira (elvis-teixeira) wrote :

I have prepended the source container name to the versioned object to
be stored, a patch was submitted

Revision history for this message
Elvis Teixeira (elvis-teixeira) wrote :

Mr. Samuel Merritt warned me that my change would break compatibility with existing
code, and jenkins tests failed because they expeced the old-fashioned logic. I have a new
change proposal that includes backwards comatibility and the corresponding changes in the
test cases. I am commiting it now.

Changed in python-swiftclient:
status: Confirmed → In Progress
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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