Container delete + re-creation can retain old ACL permissions
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Object Storage (swift) |
Fix Released
|
Critical
|
John Dickinson |
Bug Description
I've reproduced an eventual consistency issue with container on swift 1.4.3, that may present a swcurity concern,
I think reidrac (see #openstack-dev @ ~ 2011-08-26T11) has used a newer version to also repro it.
If a container with ACLS is deleted and promptly recreated, it retains its ACL settings.
orrigac@
backup
id
corrigac@
Account: AUTH_0be52345-
Container: id
Objects: 1
Bytes: 91
Read ACL:
Write ACL:
Sync To:
Sync Key:
Accept-Ranges: bytes
X-Trans-Id: tx021ecbb6ad104
corrigac@
corrigac@
Account: AUTH_0be52345-
Container: id
Objects: 1
Bytes: 91
Read ACL: *
Write ACL:
Sync To:
Sync Key:
Accept-Ranges: bytes
X-Trans-Id: tx2603dee3abb94
corrigac@
tmp/myid
corrigac@
Container 'id' not found
corrigac@
myid
corrigac@
Account: AUTH_0be52345-
Container: id
Objects: 1
Bytes: 172
Read ACL: *
Write ACL:
Sync To:
Sync Key:
Accept-Ranges: bytes
X-Trans-Id: tx4abdf56ec54e4
corrigac@
corrigac@
Account: AUTH_0be52345-
Container: id
Objects: 0
Bytes: 0
Read ACL:
Write ACL:
Sync To:
Sync Key:
Accept-Ranges: bytes
X-Trans-Id: tx4addacc688f24
corrigac@
corrigac@
corrigac@
Account: AUTH_0be52345-
Container: id
Objects: 0
Bytes: 0
Read ACL:
Write ACL:
Sync To:
Sync Key:
Accept-Ranges: bytes
X-Trans-Id: tx6bcf137363004
Related branches
- Chuck Thier (community): Approve
- gholt (community): Approve
-
Diff: 65 lines (+26/-5)2 files modifiedswift/common/db.py (+6/-0)
test/unit/common/test_db.py (+20/-5)
Changed in swift: | |
assignee: | nobody → John Dickinson (notmyname) |
status: | New → Confirmed |
importance: | Undecided → High |
importance: | High → Critical |
milestone: | none → 1.4.3 |
Changed in swift: | |
status: | Confirmed → Fix Committed |
Changed in swift: | |
status: | Fix Committed → Fix Released |
information type: | Private Security → Public Security |
This is actually a bug, not a consistency issue. The bug is that the metadata isn't explicitly cleared when the container is marked deleted. So if a PUT comes in before the reclaimer deletes the db, all of the container metadata gets resurrected.