swift-ring-builder - empty device name

Bug #1438579 reported by Ondřej Nový
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
Fix Released
Undecided
Christian Schwede

Bug Description

swift-ring builder allows to create device with empty device_name:

root@swift1:~# swift-ring-builder account.builder create 10 3 1
root@swift1:~# swift-ring-builder account.builder add r1z1-127.0.0.1:6012/ 1
Device d0r1z1-127.0.0.1:6012R127.0.0.1:6012/_"" weight 1.0
root@swift1:~# swift-ring-builder account.builder
account.builder, build version 1
1024 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 100.00 balance, 0.00 dispersion
The minimum number of hours before a partition can be reassigned is 1
The overload factor is 0.00% (0.000000)
Devices: id region zone ip address port replication ip replication port name weight partitions balance meta
             0 1 1 127.0.0.1 6012 127.0.0.1 6012 1.00 0 -100.00

This ring is unusable then, when i try to do any operation on Swift:

Mar 30 14:02:51 swift1 account-server: 10.0.162.46 - - [30/Mar/2015:12:02:51 +0000] "HEAD //928653/v1.0" 400 27 "HEAD http://127.0.0.1:8080/v1
/v1.0" "txe184bd485dd94793ac655-0055193b6b" "proxy-server 3357" 0.0014 "-" 3350

If i recreated same ring with device name "a", everything is working fine:
Mar 30 15:15:31 swift1 account-server: 10.0.162.46 - - [30/Mar/2015:13:15:31 +0000] "GET /a/385843/AUTH_test" 200 2 "GET http://127.0.0.1:8080
/v1/AUTH_test?format=json&marker=test2" "tx9ebf6882fef840e6ac60c-0055194c73" "proxy-server 4786" 0.0102 "-" 4780

I think device_name is required parameter and swift-ring-builder shouldn't allow to add device without device_name.

CVE References

Revision history for this message
Christian Schwede (cschwede) wrote :

Thanks for the bug report!

You're right, this is not very nice. Additionally it is possible to use device names with a leading or trailing space, which might make problems as well, for example this one:

swift-ring-builder account.builder add r1z1-127.0.0.1:6012/ met data 1

Now you have a device assigned called " meta data".

I'll commit a fix for this.

Changed in swift:
status: New → Confirmed
assignee: nobody → Christian Schwede (cschwede)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (master)

Fix proposed to branch: master
Review: https://review.openstack.org/169231

Changed in swift:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (master)

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

commit d3213fb1fe00ae649ba198577b7e8b37180d3753
Author: Christian Schwede <email address hidden>
Date: Tue Mar 31 08:51:18 2015 +0000

    Check if device name is valid when adding to the ring

    Currently device names can be empty or start and/or end with spaces.
    This can create unexpected results, for example these three commands
    are all valid:

    swift-ring-builder account.builder add "r1z1-127.0.0.1:6000/" 1
    swift-ring-builder account.builder add "r1z1-127.0.0.1:6000/sda " 1
    swift-ring-builder account.builder add "r1z1-127.0.0.1:6000/ meta" 1

    This patch validates device names and prevents empty names or names
    starting and/or ending with spaces.

    Also fixed the test "test_warn_at_risk" - the test passed if the
    exception was not raised.

    Closes-Bug: 1438579

    Change-Id: I811b0eae7db503279e6429d985275bbab8b29c9f

Changed in swift:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in swift:
milestone: none → 2.3.0-rc1
status: Fix Committed → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (feature/crypto)

Fix proposed to branch: feature/crypto
Review: https://review.openstack.org/175866

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (feature/crypto)
Download full text (39.4 KiB)

Reviewed: https://review.openstack.org/175866
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=5bb7c286ebb4a54e4d2bd5a02845644d1c651183
Submitter: Jenkins
Branch: feature/crypto

commit e440d6aed8a40848584767ed36811bf09c738838
Author: Kota Tsuyuzaki <email address hidden>
Date: Wed Apr 15 11:25:13 2015 -0700

    Fix best response to return correct status

    Current best response could return "503 Internal Server Error".
    However, "503" means "Service Unavailable". (The status int of
    Internal Server Error is 500)

    This patch fixes the response status as "503 Service Unavailable"

    Change-Id: I88b8c52c26b19e9e76ba3375f1e16ced555ed54c

commit 57011d5699d49a47ae89073ff27b39140ab4d652
Author: Ricardo Ferreira <email address hidden>
Date: Thu Mar 12 23:18:33 2015 +0000

    More user-friendly output for object metadata

    Split out system, user and other metadata in swift-object-info. Print
    every position line by line instead of raw dict representation, so it
    would be easier to parse with tools such as grep.

    Co-Authored-By: Ricardo Ferreira <email address hidden>
    Co-Authored-By: Kamil Rykowski <email address hidden>

    Change-Id: Ia78da518c18f7e26016700aee87efb534fbd2040
    Closes-Bug: #1428866

commit a162c2bdd7be12daa29dd07230f84efcaf1cab37
Author: OpenStack Proposal Bot <email address hidden>
Date: Thu Apr 16 06:06:35 2015 +0000

    Imported Translations from Transifex

    For more information about this automatic import see:
    https://wiki.openstack.org/wiki/Translations/Infrastructure

    Change-Id: I48ba06f4801ff2d7856d67e74d2b1f76c550fcf4

commit 52b102163e48dc04a6a492a3430efa1f7778d7ec
Author: Clay Gerrard <email address hidden>
Date: Wed Apr 15 15:31:06 2015 -0700

    Don't apply the wrong Etag validation to rebuilt fragments

    Because of the object-server's interaction with ssync sender's
    X-Backend-Replication-Headers when a object (or fragment archive) is
    pushed unmodified to another node it's ETag value is duped into the
    recieving ends metadata as Etag. This interacts poorly with the
    reconstructor's RebuildingECDiskFileStream which can not know ahead of
    time the ETag of the fragment archive being rebuilt.

    Don't send the Etag from the local source fragment archive being used as
    the basis for the rebuilt fragent archive's metadata along to ssync.

    Change-Id: Ie59ad93a67a7f439c9a84cd9cff31540f97f334a

commit 46bd6716ffae28aef53f15af170fd2df01b49843
Author: Kota Tsuyuzaki <email address hidden>
Date: Tue Apr 14 23:22:14 2015 -0700

    Small minor refactor on ec diskfile

    To be more helpful, add an inline comment and remove
    unnecessary assignment.

    Change-Id: Ia9c6993dfa03c238736955de8b0f5c1a7d5d1b65

commit 193fe9a5f906a2344bb5d328ad55b881e4086caa
Author: Lorcan <email address hidden>
Date: Wed Apr 15 11:32:32 2015 +0100

    Update swift-recon doc with more options

    The swit-recon tool has had several functional additions
    added recently but not all of these have been added to the docs.

    This change add...

Thierry Carrez (ttx)
Changed in swift:
milestone: 2.3.0-rc1 → 2.3.0
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.