2013-09-20 01:00:54 +08:00
|
|
|
# Copyright (c) 2010-2012 OpenStack Foundation
|
2013-03-30 15:55:29 +03:00
|
|
|
#
|
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
# you may not use this file except in compliance with the License.
|
|
|
|
# You may obtain a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
|
|
# implied.
|
|
|
|
# See the License for the specific language governing permissions and
|
|
|
|
# limitations under the License.
|
|
|
|
|
|
|
|
import mock
|
|
|
|
import unittest
|
|
|
|
|
Privileged acct ACL header, new ACL syntax, TempAuth impl.
* Introduce a new privileged account header: X-Account-Access-Control
* Introduce JSON-based version 2 ACL syntax -- see below for discussion
* Implement account ACL authorization in TempAuth
X-Account-Access-Control Header
-------------------------------
Accounts now have a new privileged header to represent ACLs or any other
form of account-level access control. The value of the header is an opaque
string to be interpreted by the auth system, but it must be a JSON-encoded
dictionary. A reference implementation is given in TempAuth, with the
knowledge that historically other auth systems often use TempAuth as a
starting point.
The reference implementation describes three levels of account access:
"admin", "read-write", and "read-only". Adding new access control
features in a future patch (e.g. "write-only" account access) will
automatically be forward- and backward-compatible, due to the JSON
dictionary header format.
The privileged X-Account-Access-Control header may only be read or written
by a user with "swift_owner" status, traditionally the account owner but
now also any user on the "admin" ACL.
Access Levels:
Read-only access is intended to indicate to the auth system that this
list of identities can read everything (except privileged headers) in
the account. Specifically, a user with read-only account access can get
a list of containers in the account, list the contents of any container,
retrieve any object, and see the (non-privileged) headers of the
account, any container, or any object.
Read-write access is intended to indicate to the auth system that this
list of identities can read or write (or create) any container. A user
with read-write account access can create new containers, set any
unprivileged container headers, overwrite objects, delete containers,
etc. A read-write user can NOT set account headers (or perform any
PUT/POST/DELETE requests on the account).
Admin access is intended to indicate to the auth system that this list of
identities has "swift_owner" privileges. A user with admin account access
can do anything the account owner can, including setting account headers
and any privileged headers -- and thus changing the value of
X-Account-Access-Control and thereby granting read-only, read-write, or
admin access to other users.
The auth system is responsible for making decisions based on this header,
if it chooses to support its use. Therefore the above access level
descriptions are necessarily advisory only for other auth systems.
When setting the value of the header, callers are urged to use the new
format_acl() method, described below.
New ACL Format
--------------
The account ACLs introduce a new format for ACLs, rather than reusing the
existing format from X-Container-Read/X-Container-Write. There are several
reasons for this:
* Container ACL format does not support Unicode
* Container ACLs have a different structure than account ACLs
+ account ACLs have no concept of referrers or rlistings
+ accounts have additional "admin" access level
+ account access levels are structured as admin > rw > ro, which seems more
appropriate for how people access accounts, rather than reusing
container ACLs' orthogonal read and write access
In addition, the container ACL syntax is a bit arbitrary and highly custom,
so instead of parsing additional custom syntax, I'd rather propose a next
version and introduce a means for migration. The V2 ACL syntax has the
following benefits:
* JSON is a well-known standard syntax with parsers in all languages
* no artificial value restrictions (you can grant access to a user named
".rlistings" if you want)
* forward and backward compatibility: you may have extraneous keys, but
your attempt to parse the header won't raise an exception
I've introduced hooks in parse_acl and format_acl which currently default
to the old V1 syntax but tolerate the V2 syntax and can easily be flipped
to default to V2. I'm not changing the default or adding code to rewrite
V1 ACLs to V2, because this patch has suffered a lot of scope creep already,
but this seems like a sensible milestone in the migration.
TempAuth Account ACL Implementation
-----------------------------------
As stated above, core Swift is responsible for privileging the
X-Account-Access-Control header (making it only accessible to swift_owners),
for translating it to -sysmeta-* headers to trigger persistence by the
account server, and for including the header in the responses to requests
by privileged users. Core Swift puts no expectation on the *content* of
this header. Auth systems (including TempAuth) are responsible for
defining the content of the header and taking action based on it.
In addition to the changes described above, this patch defines a format
to be used by TempAuth for these headers in the common.middleware.acl
module, in the methods format_v2_acl() and parse_v2_acl(). This patch
also teaches TempAuth to take action based on the header contents. TempAuth
now sets swift_owner=True if the user is on the Admin ACL, authorizes
GET/HEAD/OPTIONS requests if the user is on any ACL, authorizes
PUT/POST/DELETE requests if the user is on the admin or read-write ACL, etc.
Note that the action of setting swift_owner=True triggers core Swift to
add or strip the privileged headers from the responses. Core Swift (not
the auth system) is responsible for that.
DocImpact: Documentation for the new ACL usage and format appears in
summary form in doc/source/overview_auth.rst, and in more detail in
swift/common/middleware/tempauth.py in the TempAuth class docstring.
I leave it to the Swift doc team to determine whether more is needed.
Change-Id: I836a99eaaa6bb0e92dc03e1ca46a474522e6e826
2013-11-13 20:55:14 +00:00
|
|
|
from swift.common.swob import Request, Response
|
|
|
|
from swift.common.middleware.acl import format_acl
|
2013-03-30 15:55:29 +03:00
|
|
|
from swift.proxy import server as proxy_server
|
|
|
|
from swift.proxy.controllers.base import headers_to_account_info
|
2014-04-02 16:16:21 -04:00
|
|
|
from swift.common import constraints
|
2013-03-30 15:55:29 +03:00
|
|
|
from test.unit import fake_http_connect, FakeRing, FakeMemcache
|
2014-05-27 01:17:13 -07:00
|
|
|
from swift.common.storage_policy import StoragePolicy
|
2013-12-03 22:02:39 +00:00
|
|
|
from swift.common.request_helpers import get_sys_meta_prefix
|
Privileged acct ACL header, new ACL syntax, TempAuth impl.
* Introduce a new privileged account header: X-Account-Access-Control
* Introduce JSON-based version 2 ACL syntax -- see below for discussion
* Implement account ACL authorization in TempAuth
X-Account-Access-Control Header
-------------------------------
Accounts now have a new privileged header to represent ACLs or any other
form of account-level access control. The value of the header is an opaque
string to be interpreted by the auth system, but it must be a JSON-encoded
dictionary. A reference implementation is given in TempAuth, with the
knowledge that historically other auth systems often use TempAuth as a
starting point.
The reference implementation describes three levels of account access:
"admin", "read-write", and "read-only". Adding new access control
features in a future patch (e.g. "write-only" account access) will
automatically be forward- and backward-compatible, due to the JSON
dictionary header format.
The privileged X-Account-Access-Control header may only be read or written
by a user with "swift_owner" status, traditionally the account owner but
now also any user on the "admin" ACL.
Access Levels:
Read-only access is intended to indicate to the auth system that this
list of identities can read everything (except privileged headers) in
the account. Specifically, a user with read-only account access can get
a list of containers in the account, list the contents of any container,
retrieve any object, and see the (non-privileged) headers of the
account, any container, or any object.
Read-write access is intended to indicate to the auth system that this
list of identities can read or write (or create) any container. A user
with read-write account access can create new containers, set any
unprivileged container headers, overwrite objects, delete containers,
etc. A read-write user can NOT set account headers (or perform any
PUT/POST/DELETE requests on the account).
Admin access is intended to indicate to the auth system that this list of
identities has "swift_owner" privileges. A user with admin account access
can do anything the account owner can, including setting account headers
and any privileged headers -- and thus changing the value of
X-Account-Access-Control and thereby granting read-only, read-write, or
admin access to other users.
The auth system is responsible for making decisions based on this header,
if it chooses to support its use. Therefore the above access level
descriptions are necessarily advisory only for other auth systems.
When setting the value of the header, callers are urged to use the new
format_acl() method, described below.
New ACL Format
--------------
The account ACLs introduce a new format for ACLs, rather than reusing the
existing format from X-Container-Read/X-Container-Write. There are several
reasons for this:
* Container ACL format does not support Unicode
* Container ACLs have a different structure than account ACLs
+ account ACLs have no concept of referrers or rlistings
+ accounts have additional "admin" access level
+ account access levels are structured as admin > rw > ro, which seems more
appropriate for how people access accounts, rather than reusing
container ACLs' orthogonal read and write access
In addition, the container ACL syntax is a bit arbitrary and highly custom,
so instead of parsing additional custom syntax, I'd rather propose a next
version and introduce a means for migration. The V2 ACL syntax has the
following benefits:
* JSON is a well-known standard syntax with parsers in all languages
* no artificial value restrictions (you can grant access to a user named
".rlistings" if you want)
* forward and backward compatibility: you may have extraneous keys, but
your attempt to parse the header won't raise an exception
I've introduced hooks in parse_acl and format_acl which currently default
to the old V1 syntax but tolerate the V2 syntax and can easily be flipped
to default to V2. I'm not changing the default or adding code to rewrite
V1 ACLs to V2, because this patch has suffered a lot of scope creep already,
but this seems like a sensible milestone in the migration.
TempAuth Account ACL Implementation
-----------------------------------
As stated above, core Swift is responsible for privileging the
X-Account-Access-Control header (making it only accessible to swift_owners),
for translating it to -sysmeta-* headers to trigger persistence by the
account server, and for including the header in the responses to requests
by privileged users. Core Swift puts no expectation on the *content* of
this header. Auth systems (including TempAuth) are responsible for
defining the content of the header and taking action based on it.
In addition to the changes described above, this patch defines a format
to be used by TempAuth for these headers in the common.middleware.acl
module, in the methods format_v2_acl() and parse_v2_acl(). This patch
also teaches TempAuth to take action based on the header contents. TempAuth
now sets swift_owner=True if the user is on the Admin ACL, authorizes
GET/HEAD/OPTIONS requests if the user is on any ACL, authorizes
PUT/POST/DELETE requests if the user is on the admin or read-write ACL, etc.
Note that the action of setting swift_owner=True triggers core Swift to
add or strip the privileged headers from the responses. Core Swift (not
the auth system) is responsible for that.
DocImpact: Documentation for the new ACL usage and format appears in
summary form in doc/source/overview_auth.rst, and in more detail in
swift/common/middleware/tempauth.py in the TempAuth class docstring.
I leave it to the Swift doc team to determine whether more is needed.
Change-Id: I836a99eaaa6bb0e92dc03e1ca46a474522e6e826
2013-11-13 20:55:14 +00:00
|
|
|
import swift.proxy.controllers.base
|
Fix up get_account_info and get_container_info
get_account_info used to work like this:
* make an account HEAD request
* ignore the response
* get the account info by digging around in the request environment,
where it had been deposited by elves or something
Not actually elves, but the proxy's GETorHEAD_base method would take
the HEAD response and cache it in the response environment, which was
the same object as the request environment, thus enabling
get_account_info to find it.
This was extraordinarily brittle. If a WSGI middleware were to
shallow-copy the request environment, then any middlewares to its left
could not use get_account_info, as the left middleware's request
environment would no longer be identical to the response environment
down in GETorHEAD_base.
Now, get_account_info works like this:
* make an account HEAD request.
* if the account info is in the request environment, return it. This
is an optimization to avoid a double-set in memcached.
* else, compute the account info from the response headers, store it
in caches, and return it.
This is much easier to think about; get_account_info can get and cache
account info all on its own; the cache check and cache set are right
next to each other.
All the above is true for get_container_info as well.
get_info() is still around, but it's just a shim. It was trying to
unify get_account_info and get_container_info to exploit the
commonalities, but the number of times that "if container:" showed up
in get_info and its helpers really indicated that something was
wrong. I'd rather have two functions with some duplication than one
function with no duplication but a bunch of "if container:" branches.
Other things of note:
* a HEAD request to a deleted account returns 410, but
get_account_info would return 404 since the 410 came from the
account controller *after* GETorHEAD_base ran. Now
get_account_info returns 410 as well.
* cache validity period (recheck_account_existence and
recheck_container_existence) is now communicated to
get_account_info via an X-Backend header. This way,
get_account_info doesn't need a reference to the
swift.proxy.server.Application object.
* both logged swift_source values are now correct for
get_container_info calls; before, on a cold cache,
get_container_info would call get_account_info but not pass along
swift_source, resulting in get_account_info logging "GET_INFO" as
the source. Amusingly, there was a unit test asserting this bogus
behavior.
* callers that modify the return value of get_account_info or of
get_container_info don't modify what's stored in swift.infocache.
* get_account_info on an account that *can* be autocreated but has
not been will return a 200, same as a HEAD request. The old
behavior was a 404 from get_account_info but a 200 from
HEAD. Callers can tell the difference by looking at
info['account_really_exists'] if they need to know the difference
(there is one call site that needs to know, in container
PUT). Note: this is for all accounts when the proxy's
"account_autocreate" setting is on.
Change-Id: I5167714025ec7237f7e6dd4759c2c6eb959b3fca
2016-02-11 15:51:45 -08:00
|
|
|
from swift.proxy.controllers.base import get_account_info
|
2013-03-30 15:55:29 +03:00
|
|
|
|
2014-05-27 01:17:13 -07:00
|
|
|
from test.unit import patch_policies
|
2013-03-30 15:55:29 +03:00
|
|
|
|
2014-05-27 01:17:13 -07:00
|
|
|
|
|
|
|
@patch_policies([StoragePolicy(0, 'zero', True, object_ring=FakeRing())])
|
2013-03-30 15:55:29 +03:00
|
|
|
class TestAccountController(unittest.TestCase):
|
|
|
|
def setUp(self):
|
2014-05-27 01:17:13 -07:00
|
|
|
self.app = proxy_server.Application(
|
|
|
|
None, FakeMemcache(),
|
|
|
|
account_ring=FakeRing(), container_ring=FakeRing())
|
2013-03-30 15:55:29 +03:00
|
|
|
|
2016-01-22 05:19:06 +00:00
|
|
|
def _make_callback_func(self, context):
|
|
|
|
def callback(ipaddr, port, device, partition, method, path,
|
|
|
|
headers=None, query_string=None, ssl=False):
|
|
|
|
context['method'] = method
|
|
|
|
context['path'] = path
|
|
|
|
context['headers'] = headers or {}
|
|
|
|
return callback
|
|
|
|
|
|
|
|
def _assert_responses(self, method, test_cases):
|
|
|
|
if method in ('PUT', 'DELETE'):
|
|
|
|
self.app.allow_account_management = True
|
|
|
|
controller = proxy_server.AccountController(self.app, 'AUTH_bob')
|
|
|
|
|
|
|
|
for responses, expected in test_cases:
|
|
|
|
with mock.patch(
|
|
|
|
'swift.proxy.controllers.base.http_connect',
|
|
|
|
fake_http_connect(*responses)):
|
|
|
|
req = Request.blank('/v1/AUTH_bob')
|
|
|
|
resp = getattr(controller, method)(req)
|
|
|
|
|
|
|
|
self.assertEqual(expected,
|
|
|
|
resp.status_int,
|
|
|
|
'Expected %s but got %s. Failed case: %s' %
|
|
|
|
(expected, resp.status_int, str(responses)))
|
|
|
|
|
2013-03-30 15:55:29 +03:00
|
|
|
def test_account_info_in_response_env(self):
|
|
|
|
controller = proxy_server.AccountController(self.app, 'AUTH_bob')
|
|
|
|
with mock.patch('swift.proxy.controllers.base.http_connect',
|
2013-10-28 17:28:57 -07:00
|
|
|
fake_http_connect(200, body='')):
|
Stop mutating PATH_INFO in proxy server
The proxy server was calling swob.Request.path_info_pop() prior to
instantiating a controller so that req.path_info was just /a/c/o (sans
/v1). The version got moved over into SCRIPT_NAME.
This lead to some unfortunate behavior when trying to re-use a request
from middleware. Something like this:
# Imagine we're a WSGIContext object here.
#
# To start, SCRIPT_NAME = '' and PATH_INFO='/v1/a/c/o'
resp_iter = self._app_call(env, start_response)
# Now SCRIPT_NAME='/v1' and PATH_INFO ='/a/c/o'
if something_special in self._response_headers:
env['REQUEST_METHOD'] = 'GET'
env.pop('HTTP_RANGE', None)
# 404 SURPRISE! The proxy calls path_info_pop() again,
# and now SCRIPT_NAME='/v1/a' and PATH_INFO='/c/o', so this
# gets treated as a container request. Yikes.
resp_iter = self._app_call(env, start_response)
Now we just leave SCRIPT_NAME and PATH_INFO alone. To make life easy
for everyone who does want just /a/c/o, I defined
swob.Request.swift_entity_path, which just strips off the /v1.
Note that there's still one call to path_info_pop() in tempauth, but
that's only for requests going to /auth, so it won't affect Swift API
requests. It might be a good idea to remove that one later, but let's
do one thing at a time.
Change-Id: I87557a11c01f3f3889b610578cda6ba7d3933e7a
2013-12-03 22:18:46 -08:00
|
|
|
req = Request.blank('/v1/AUTH_bob', {'PATH_INFO': '/v1/AUTH_bob'})
|
2013-03-30 15:55:29 +03:00
|
|
|
resp = controller.HEAD(req)
|
|
|
|
self.assertEqual(2, resp.status_int // 100)
|
2016-04-27 13:31:11 -05:00
|
|
|
self.assertIn('account/AUTH_bob', resp.environ['swift.infocache'])
|
Make info caching work across subrequests
Previously, if you called get_account_info, get_container_info, or
get_object_info, then the results of that call would be cached in the
WSGI environment as top-level keys. This is okay, except that if you,
in middleware, copy the WSGI environment and then make a subrequest
using the copy, information retrieved in the subrequest is cached
only in the copy and not in the original. This can mean lots of extra
trips to memcache for, say, SLO validation where the segments are in
another container; the object HEAD ends up getting container info for
the segment container, but then the next object HEAD gets it again.
This commit moves the cache for get_*_info into a dictionary at
environ['swift.infocache']; this way, you can shallow-copy the request
environment and still get the benefits from the cache.
Change-Id: I3481b38b41c33cd1e39e19baab56193c5f9bf6ac
2016-01-21 13:19:30 -08:00
|
|
|
self.assertEqual(
|
|
|
|
headers_to_account_info(resp.headers),
|
2016-04-27 13:31:11 -05:00
|
|
|
resp.environ['swift.infocache']['account/AUTH_bob'])
|
2013-03-30 15:55:29 +03:00
|
|
|
|
2013-06-27 14:11:25 +00:00
|
|
|
def test_swift_owner(self):
|
|
|
|
owner_headers = {
|
|
|
|
'x-account-meta-temp-url-key': 'value',
|
|
|
|
'x-account-meta-temp-url-key-2': 'value'}
|
|
|
|
controller = proxy_server.AccountController(self.app, 'a')
|
|
|
|
|
Stop mutating PATH_INFO in proxy server
The proxy server was calling swob.Request.path_info_pop() prior to
instantiating a controller so that req.path_info was just /a/c/o (sans
/v1). The version got moved over into SCRIPT_NAME.
This lead to some unfortunate behavior when trying to re-use a request
from middleware. Something like this:
# Imagine we're a WSGIContext object here.
#
# To start, SCRIPT_NAME = '' and PATH_INFO='/v1/a/c/o'
resp_iter = self._app_call(env, start_response)
# Now SCRIPT_NAME='/v1' and PATH_INFO ='/a/c/o'
if something_special in self._response_headers:
env['REQUEST_METHOD'] = 'GET'
env.pop('HTTP_RANGE', None)
# 404 SURPRISE! The proxy calls path_info_pop() again,
# and now SCRIPT_NAME='/v1/a' and PATH_INFO='/c/o', so this
# gets treated as a container request. Yikes.
resp_iter = self._app_call(env, start_response)
Now we just leave SCRIPT_NAME and PATH_INFO alone. To make life easy
for everyone who does want just /a/c/o, I defined
swob.Request.swift_entity_path, which just strips off the /v1.
Note that there's still one call to path_info_pop() in tempauth, but
that's only for requests going to /auth, so it won't affect Swift API
requests. It might be a good idea to remove that one later, but let's
do one thing at a time.
Change-Id: I87557a11c01f3f3889b610578cda6ba7d3933e7a
2013-12-03 22:18:46 -08:00
|
|
|
req = Request.blank('/v1/a')
|
2013-06-27 14:11:25 +00:00
|
|
|
with mock.patch('swift.proxy.controllers.base.http_connect',
|
2013-10-28 17:28:57 -07:00
|
|
|
fake_http_connect(200, headers=owner_headers)):
|
2013-06-27 14:11:25 +00:00
|
|
|
resp = controller.HEAD(req)
|
2015-08-06 10:01:17 -05:00
|
|
|
self.assertEqual(2, resp.status_int // 100)
|
2013-06-27 14:11:25 +00:00
|
|
|
for key in owner_headers:
|
2016-07-15 15:02:00 +02:00
|
|
|
self.assertNotIn(key, resp.headers)
|
2013-06-27 14:11:25 +00:00
|
|
|
|
Stop mutating PATH_INFO in proxy server
The proxy server was calling swob.Request.path_info_pop() prior to
instantiating a controller so that req.path_info was just /a/c/o (sans
/v1). The version got moved over into SCRIPT_NAME.
This lead to some unfortunate behavior when trying to re-use a request
from middleware. Something like this:
# Imagine we're a WSGIContext object here.
#
# To start, SCRIPT_NAME = '' and PATH_INFO='/v1/a/c/o'
resp_iter = self._app_call(env, start_response)
# Now SCRIPT_NAME='/v1' and PATH_INFO ='/a/c/o'
if something_special in self._response_headers:
env['REQUEST_METHOD'] = 'GET'
env.pop('HTTP_RANGE', None)
# 404 SURPRISE! The proxy calls path_info_pop() again,
# and now SCRIPT_NAME='/v1/a' and PATH_INFO='/c/o', so this
# gets treated as a container request. Yikes.
resp_iter = self._app_call(env, start_response)
Now we just leave SCRIPT_NAME and PATH_INFO alone. To make life easy
for everyone who does want just /a/c/o, I defined
swob.Request.swift_entity_path, which just strips off the /v1.
Note that there's still one call to path_info_pop() in tempauth, but
that's only for requests going to /auth, so it won't affect Swift API
requests. It might be a good idea to remove that one later, but let's
do one thing at a time.
Change-Id: I87557a11c01f3f3889b610578cda6ba7d3933e7a
2013-12-03 22:18:46 -08:00
|
|
|
req = Request.blank('/v1/a', environ={'swift_owner': True})
|
2013-06-27 14:11:25 +00:00
|
|
|
with mock.patch('swift.proxy.controllers.base.http_connect',
|
2013-10-28 17:28:57 -07:00
|
|
|
fake_http_connect(200, headers=owner_headers)):
|
2013-06-27 14:11:25 +00:00
|
|
|
resp = controller.HEAD(req)
|
2015-08-06 10:01:17 -05:00
|
|
|
self.assertEqual(2, resp.status_int // 100)
|
2013-06-27 14:11:25 +00:00
|
|
|
for key in owner_headers:
|
2016-07-15 15:02:00 +02:00
|
|
|
self.assertIn(key, resp.headers)
|
2013-06-27 14:11:25 +00:00
|
|
|
|
2013-10-28 17:28:57 -07:00
|
|
|
def test_get_deleted_account(self):
|
|
|
|
resp_headers = {
|
|
|
|
'x-account-status': 'deleted',
|
|
|
|
}
|
|
|
|
controller = proxy_server.AccountController(self.app, 'a')
|
|
|
|
|
Stop mutating PATH_INFO in proxy server
The proxy server was calling swob.Request.path_info_pop() prior to
instantiating a controller so that req.path_info was just /a/c/o (sans
/v1). The version got moved over into SCRIPT_NAME.
This lead to some unfortunate behavior when trying to re-use a request
from middleware. Something like this:
# Imagine we're a WSGIContext object here.
#
# To start, SCRIPT_NAME = '' and PATH_INFO='/v1/a/c/o'
resp_iter = self._app_call(env, start_response)
# Now SCRIPT_NAME='/v1' and PATH_INFO ='/a/c/o'
if something_special in self._response_headers:
env['REQUEST_METHOD'] = 'GET'
env.pop('HTTP_RANGE', None)
# 404 SURPRISE! The proxy calls path_info_pop() again,
# and now SCRIPT_NAME='/v1/a' and PATH_INFO='/c/o', so this
# gets treated as a container request. Yikes.
resp_iter = self._app_call(env, start_response)
Now we just leave SCRIPT_NAME and PATH_INFO alone. To make life easy
for everyone who does want just /a/c/o, I defined
swob.Request.swift_entity_path, which just strips off the /v1.
Note that there's still one call to path_info_pop() in tempauth, but
that's only for requests going to /auth, so it won't affect Swift API
requests. It might be a good idea to remove that one later, but let's
do one thing at a time.
Change-Id: I87557a11c01f3f3889b610578cda6ba7d3933e7a
2013-12-03 22:18:46 -08:00
|
|
|
req = Request.blank('/v1/a')
|
2013-10-28 17:28:57 -07:00
|
|
|
with mock.patch('swift.proxy.controllers.base.http_connect',
|
|
|
|
fake_http_connect(404, headers=resp_headers)):
|
|
|
|
resp = controller.HEAD(req)
|
2015-08-06 10:01:17 -05:00
|
|
|
self.assertEqual(410, resp.status_int)
|
2013-10-28 17:28:57 -07:00
|
|
|
|
|
|
|
def test_long_acct_names(self):
|
2014-04-02 16:16:21 -04:00
|
|
|
long_acct_name = '%sLongAccountName' % (
|
|
|
|
'Very' * (constraints.MAX_ACCOUNT_NAME_LENGTH // 4))
|
2013-10-28 17:28:57 -07:00
|
|
|
controller = proxy_server.AccountController(self.app, long_acct_name)
|
|
|
|
|
Stop mutating PATH_INFO in proxy server
The proxy server was calling swob.Request.path_info_pop() prior to
instantiating a controller so that req.path_info was just /a/c/o (sans
/v1). The version got moved over into SCRIPT_NAME.
This lead to some unfortunate behavior when trying to re-use a request
from middleware. Something like this:
# Imagine we're a WSGIContext object here.
#
# To start, SCRIPT_NAME = '' and PATH_INFO='/v1/a/c/o'
resp_iter = self._app_call(env, start_response)
# Now SCRIPT_NAME='/v1' and PATH_INFO ='/a/c/o'
if something_special in self._response_headers:
env['REQUEST_METHOD'] = 'GET'
env.pop('HTTP_RANGE', None)
# 404 SURPRISE! The proxy calls path_info_pop() again,
# and now SCRIPT_NAME='/v1/a' and PATH_INFO='/c/o', so this
# gets treated as a container request. Yikes.
resp_iter = self._app_call(env, start_response)
Now we just leave SCRIPT_NAME and PATH_INFO alone. To make life easy
for everyone who does want just /a/c/o, I defined
swob.Request.swift_entity_path, which just strips off the /v1.
Note that there's still one call to path_info_pop() in tempauth, but
that's only for requests going to /auth, so it won't affect Swift API
requests. It might be a good idea to remove that one later, but let's
do one thing at a time.
Change-Id: I87557a11c01f3f3889b610578cda6ba7d3933e7a
2013-12-03 22:18:46 -08:00
|
|
|
req = Request.blank('/v1/%s' % long_acct_name)
|
2013-10-28 17:28:57 -07:00
|
|
|
with mock.patch('swift.proxy.controllers.base.http_connect',
|
|
|
|
fake_http_connect(200)):
|
|
|
|
resp = controller.HEAD(req)
|
2015-08-06 10:01:17 -05:00
|
|
|
self.assertEqual(400, resp.status_int)
|
2013-10-28 17:28:57 -07:00
|
|
|
|
|
|
|
with mock.patch('swift.proxy.controllers.base.http_connect',
|
|
|
|
fake_http_connect(200)):
|
|
|
|
resp = controller.GET(req)
|
2015-08-06 10:01:17 -05:00
|
|
|
self.assertEqual(400, resp.status_int)
|
2013-10-28 17:28:57 -07:00
|
|
|
|
|
|
|
with mock.patch('swift.proxy.controllers.base.http_connect',
|
|
|
|
fake_http_connect(200)):
|
|
|
|
resp = controller.POST(req)
|
2015-08-06 10:01:17 -05:00
|
|
|
self.assertEqual(400, resp.status_int)
|
2013-10-28 17:28:57 -07:00
|
|
|
|
2013-12-03 22:02:39 +00:00
|
|
|
def test_sys_meta_headers_PUT(self):
|
|
|
|
# check that headers in sys meta namespace make it through
|
|
|
|
# the proxy controller
|
|
|
|
sys_meta_key = '%stest' % get_sys_meta_prefix('account')
|
|
|
|
sys_meta_key = sys_meta_key.title()
|
|
|
|
user_meta_key = 'X-Account-Meta-Test'
|
|
|
|
# allow PUTs to account...
|
|
|
|
self.app.allow_account_management = True
|
|
|
|
controller = proxy_server.AccountController(self.app, 'a')
|
|
|
|
context = {}
|
|
|
|
callback = self._make_callback_func(context)
|
|
|
|
hdrs_in = {sys_meta_key: 'foo',
|
|
|
|
user_meta_key: 'bar',
|
|
|
|
'x-timestamp': '1.0'}
|
|
|
|
req = Request.blank('/v1/a', headers=hdrs_in)
|
|
|
|
with mock.patch('swift.proxy.controllers.base.http_connect',
|
|
|
|
fake_http_connect(200, 200, give_connect=callback)):
|
|
|
|
controller.PUT(req)
|
|
|
|
self.assertEqual(context['method'], 'PUT')
|
2016-07-15 15:02:00 +02:00
|
|
|
self.assertIn(sys_meta_key, context['headers'])
|
2013-12-03 22:02:39 +00:00
|
|
|
self.assertEqual(context['headers'][sys_meta_key], 'foo')
|
2016-07-15 15:02:00 +02:00
|
|
|
self.assertIn(user_meta_key, context['headers'])
|
2013-12-03 22:02:39 +00:00
|
|
|
self.assertEqual(context['headers'][user_meta_key], 'bar')
|
|
|
|
self.assertNotEqual(context['headers']['x-timestamp'], '1.0')
|
|
|
|
|
|
|
|
def test_sys_meta_headers_POST(self):
|
|
|
|
# check that headers in sys meta namespace make it through
|
|
|
|
# the proxy controller
|
|
|
|
sys_meta_key = '%stest' % get_sys_meta_prefix('account')
|
|
|
|
sys_meta_key = sys_meta_key.title()
|
|
|
|
user_meta_key = 'X-Account-Meta-Test'
|
|
|
|
controller = proxy_server.AccountController(self.app, 'a')
|
|
|
|
context = {}
|
|
|
|
callback = self._make_callback_func(context)
|
|
|
|
hdrs_in = {sys_meta_key: 'foo',
|
|
|
|
user_meta_key: 'bar',
|
|
|
|
'x-timestamp': '1.0'}
|
|
|
|
req = Request.blank('/v1/a', headers=hdrs_in)
|
|
|
|
with mock.patch('swift.proxy.controllers.base.http_connect',
|
|
|
|
fake_http_connect(200, 200, give_connect=callback)):
|
|
|
|
controller.POST(req)
|
|
|
|
self.assertEqual(context['method'], 'POST')
|
2016-07-15 15:02:00 +02:00
|
|
|
self.assertIn(sys_meta_key, context['headers'])
|
2013-12-03 22:02:39 +00:00
|
|
|
self.assertEqual(context['headers'][sys_meta_key], 'foo')
|
2016-07-15 15:02:00 +02:00
|
|
|
self.assertIn(user_meta_key, context['headers'])
|
2013-12-03 22:02:39 +00:00
|
|
|
self.assertEqual(context['headers'][user_meta_key], 'bar')
|
|
|
|
self.assertNotEqual(context['headers']['x-timestamp'], '1.0')
|
|
|
|
|
Privileged acct ACL header, new ACL syntax, TempAuth impl.
* Introduce a new privileged account header: X-Account-Access-Control
* Introduce JSON-based version 2 ACL syntax -- see below for discussion
* Implement account ACL authorization in TempAuth
X-Account-Access-Control Header
-------------------------------
Accounts now have a new privileged header to represent ACLs or any other
form of account-level access control. The value of the header is an opaque
string to be interpreted by the auth system, but it must be a JSON-encoded
dictionary. A reference implementation is given in TempAuth, with the
knowledge that historically other auth systems often use TempAuth as a
starting point.
The reference implementation describes three levels of account access:
"admin", "read-write", and "read-only". Adding new access control
features in a future patch (e.g. "write-only" account access) will
automatically be forward- and backward-compatible, due to the JSON
dictionary header format.
The privileged X-Account-Access-Control header may only be read or written
by a user with "swift_owner" status, traditionally the account owner but
now also any user on the "admin" ACL.
Access Levels:
Read-only access is intended to indicate to the auth system that this
list of identities can read everything (except privileged headers) in
the account. Specifically, a user with read-only account access can get
a list of containers in the account, list the contents of any container,
retrieve any object, and see the (non-privileged) headers of the
account, any container, or any object.
Read-write access is intended to indicate to the auth system that this
list of identities can read or write (or create) any container. A user
with read-write account access can create new containers, set any
unprivileged container headers, overwrite objects, delete containers,
etc. A read-write user can NOT set account headers (or perform any
PUT/POST/DELETE requests on the account).
Admin access is intended to indicate to the auth system that this list of
identities has "swift_owner" privileges. A user with admin account access
can do anything the account owner can, including setting account headers
and any privileged headers -- and thus changing the value of
X-Account-Access-Control and thereby granting read-only, read-write, or
admin access to other users.
The auth system is responsible for making decisions based on this header,
if it chooses to support its use. Therefore the above access level
descriptions are necessarily advisory only for other auth systems.
When setting the value of the header, callers are urged to use the new
format_acl() method, described below.
New ACL Format
--------------
The account ACLs introduce a new format for ACLs, rather than reusing the
existing format from X-Container-Read/X-Container-Write. There are several
reasons for this:
* Container ACL format does not support Unicode
* Container ACLs have a different structure than account ACLs
+ account ACLs have no concept of referrers or rlistings
+ accounts have additional "admin" access level
+ account access levels are structured as admin > rw > ro, which seems more
appropriate for how people access accounts, rather than reusing
container ACLs' orthogonal read and write access
In addition, the container ACL syntax is a bit arbitrary and highly custom,
so instead of parsing additional custom syntax, I'd rather propose a next
version and introduce a means for migration. The V2 ACL syntax has the
following benefits:
* JSON is a well-known standard syntax with parsers in all languages
* no artificial value restrictions (you can grant access to a user named
".rlistings" if you want)
* forward and backward compatibility: you may have extraneous keys, but
your attempt to parse the header won't raise an exception
I've introduced hooks in parse_acl and format_acl which currently default
to the old V1 syntax but tolerate the V2 syntax and can easily be flipped
to default to V2. I'm not changing the default or adding code to rewrite
V1 ACLs to V2, because this patch has suffered a lot of scope creep already,
but this seems like a sensible milestone in the migration.
TempAuth Account ACL Implementation
-----------------------------------
As stated above, core Swift is responsible for privileging the
X-Account-Access-Control header (making it only accessible to swift_owners),
for translating it to -sysmeta-* headers to trigger persistence by the
account server, and for including the header in the responses to requests
by privileged users. Core Swift puts no expectation on the *content* of
this header. Auth systems (including TempAuth) are responsible for
defining the content of the header and taking action based on it.
In addition to the changes described above, this patch defines a format
to be used by TempAuth for these headers in the common.middleware.acl
module, in the methods format_v2_acl() and parse_v2_acl(). This patch
also teaches TempAuth to take action based on the header contents. TempAuth
now sets swift_owner=True if the user is on the Admin ACL, authorizes
GET/HEAD/OPTIONS requests if the user is on any ACL, authorizes
PUT/POST/DELETE requests if the user is on the admin or read-write ACL, etc.
Note that the action of setting swift_owner=True triggers core Swift to
add or strip the privileged headers from the responses. Core Swift (not
the auth system) is responsible for that.
DocImpact: Documentation for the new ACL usage and format appears in
summary form in doc/source/overview_auth.rst, and in more detail in
swift/common/middleware/tempauth.py in the TempAuth class docstring.
I leave it to the Swift doc team to determine whether more is needed.
Change-Id: I836a99eaaa6bb0e92dc03e1ca46a474522e6e826
2013-11-13 20:55:14 +00:00
|
|
|
def _make_user_and_sys_acl_headers_data(self):
|
|
|
|
acl = {
|
|
|
|
'admin': ['AUTH_alice', 'AUTH_bob'],
|
|
|
|
'read-write': ['AUTH_carol'],
|
|
|
|
'read-only': [],
|
|
|
|
}
|
|
|
|
user_prefix = 'x-account-' # external, user-facing
|
|
|
|
user_headers = {(user_prefix + 'access-control'): format_acl(
|
|
|
|
version=2, acl_dict=acl)}
|
|
|
|
sys_prefix = get_sys_meta_prefix('account') # internal, system-facing
|
|
|
|
sys_headers = {(sys_prefix + 'core-access-control'): format_acl(
|
|
|
|
version=2, acl_dict=acl)}
|
|
|
|
return user_headers, sys_headers
|
|
|
|
|
|
|
|
def test_account_acl_headers_translated_for_GET_HEAD(self):
|
|
|
|
# Verify that a GET/HEAD which receives X-Account-Sysmeta-Acl-* headers
|
|
|
|
# from the account server will remap those headers to X-Account-Acl-*
|
|
|
|
|
|
|
|
hdrs_ext, hdrs_int = self._make_user_and_sys_acl_headers_data()
|
|
|
|
controller = proxy_server.AccountController(self.app, 'acct')
|
|
|
|
|
|
|
|
for verb in ('GET', 'HEAD'):
|
|
|
|
req = Request.blank('/v1/acct', environ={'swift_owner': True})
|
|
|
|
controller.GETorHEAD_base = lambda *_: Response(
|
|
|
|
headers=hdrs_int, environ={
|
|
|
|
'PATH_INFO': '/acct',
|
|
|
|
'REQUEST_METHOD': verb,
|
|
|
|
})
|
|
|
|
method = getattr(controller, verb)
|
|
|
|
resp = method(req)
|
|
|
|
for header, value in hdrs_ext.items():
|
|
|
|
if value:
|
|
|
|
self.assertEqual(resp.headers.get(header), value)
|
|
|
|
else:
|
|
|
|
# blank ACLs should result in no header
|
2016-07-15 15:02:00 +02:00
|
|
|
self.assertNotIn(header, resp.headers)
|
Privileged acct ACL header, new ACL syntax, TempAuth impl.
* Introduce a new privileged account header: X-Account-Access-Control
* Introduce JSON-based version 2 ACL syntax -- see below for discussion
* Implement account ACL authorization in TempAuth
X-Account-Access-Control Header
-------------------------------
Accounts now have a new privileged header to represent ACLs or any other
form of account-level access control. The value of the header is an opaque
string to be interpreted by the auth system, but it must be a JSON-encoded
dictionary. A reference implementation is given in TempAuth, with the
knowledge that historically other auth systems often use TempAuth as a
starting point.
The reference implementation describes three levels of account access:
"admin", "read-write", and "read-only". Adding new access control
features in a future patch (e.g. "write-only" account access) will
automatically be forward- and backward-compatible, due to the JSON
dictionary header format.
The privileged X-Account-Access-Control header may only be read or written
by a user with "swift_owner" status, traditionally the account owner but
now also any user on the "admin" ACL.
Access Levels:
Read-only access is intended to indicate to the auth system that this
list of identities can read everything (except privileged headers) in
the account. Specifically, a user with read-only account access can get
a list of containers in the account, list the contents of any container,
retrieve any object, and see the (non-privileged) headers of the
account, any container, or any object.
Read-write access is intended to indicate to the auth system that this
list of identities can read or write (or create) any container. A user
with read-write account access can create new containers, set any
unprivileged container headers, overwrite objects, delete containers,
etc. A read-write user can NOT set account headers (or perform any
PUT/POST/DELETE requests on the account).
Admin access is intended to indicate to the auth system that this list of
identities has "swift_owner" privileges. A user with admin account access
can do anything the account owner can, including setting account headers
and any privileged headers -- and thus changing the value of
X-Account-Access-Control and thereby granting read-only, read-write, or
admin access to other users.
The auth system is responsible for making decisions based on this header,
if it chooses to support its use. Therefore the above access level
descriptions are necessarily advisory only for other auth systems.
When setting the value of the header, callers are urged to use the new
format_acl() method, described below.
New ACL Format
--------------
The account ACLs introduce a new format for ACLs, rather than reusing the
existing format from X-Container-Read/X-Container-Write. There are several
reasons for this:
* Container ACL format does not support Unicode
* Container ACLs have a different structure than account ACLs
+ account ACLs have no concept of referrers or rlistings
+ accounts have additional "admin" access level
+ account access levels are structured as admin > rw > ro, which seems more
appropriate for how people access accounts, rather than reusing
container ACLs' orthogonal read and write access
In addition, the container ACL syntax is a bit arbitrary and highly custom,
so instead of parsing additional custom syntax, I'd rather propose a next
version and introduce a means for migration. The V2 ACL syntax has the
following benefits:
* JSON is a well-known standard syntax with parsers in all languages
* no artificial value restrictions (you can grant access to a user named
".rlistings" if you want)
* forward and backward compatibility: you may have extraneous keys, but
your attempt to parse the header won't raise an exception
I've introduced hooks in parse_acl and format_acl which currently default
to the old V1 syntax but tolerate the V2 syntax and can easily be flipped
to default to V2. I'm not changing the default or adding code to rewrite
V1 ACLs to V2, because this patch has suffered a lot of scope creep already,
but this seems like a sensible milestone in the migration.
TempAuth Account ACL Implementation
-----------------------------------
As stated above, core Swift is responsible for privileging the
X-Account-Access-Control header (making it only accessible to swift_owners),
for translating it to -sysmeta-* headers to trigger persistence by the
account server, and for including the header in the responses to requests
by privileged users. Core Swift puts no expectation on the *content* of
this header. Auth systems (including TempAuth) are responsible for
defining the content of the header and taking action based on it.
In addition to the changes described above, this patch defines a format
to be used by TempAuth for these headers in the common.middleware.acl
module, in the methods format_v2_acl() and parse_v2_acl(). This patch
also teaches TempAuth to take action based on the header contents. TempAuth
now sets swift_owner=True if the user is on the Admin ACL, authorizes
GET/HEAD/OPTIONS requests if the user is on any ACL, authorizes
PUT/POST/DELETE requests if the user is on the admin or read-write ACL, etc.
Note that the action of setting swift_owner=True triggers core Swift to
add or strip the privileged headers from the responses. Core Swift (not
the auth system) is responsible for that.
DocImpact: Documentation for the new ACL usage and format appears in
summary form in doc/source/overview_auth.rst, and in more detail in
swift/common/middleware/tempauth.py in the TempAuth class docstring.
I leave it to the Swift doc team to determine whether more is needed.
Change-Id: I836a99eaaa6bb0e92dc03e1ca46a474522e6e826
2013-11-13 20:55:14 +00:00
|
|
|
|
|
|
|
def test_add_acls_impossible_cases(self):
|
|
|
|
# For test coverage: verify that defensive coding does defend, in cases
|
|
|
|
# that shouldn't arise naturally
|
|
|
|
|
|
|
|
# add_acls should do nothing if REQUEST_METHOD isn't HEAD/GET/PUT/POST
|
|
|
|
resp = Response()
|
|
|
|
controller = proxy_server.AccountController(self.app, 'a')
|
|
|
|
resp.environ['PATH_INFO'] = '/a'
|
|
|
|
resp.environ['REQUEST_METHOD'] = 'OPTIONS'
|
|
|
|
controller.add_acls_from_sys_metadata(resp)
|
|
|
|
self.assertEqual(1, len(resp.headers)) # we always get Content-Type
|
|
|
|
self.assertEqual(2, len(resp.environ))
|
|
|
|
|
2016-04-27 13:31:11 -05:00
|
|
|
def test_cache_key_impossible_cases(self):
|
Privileged acct ACL header, new ACL syntax, TempAuth impl.
* Introduce a new privileged account header: X-Account-Access-Control
* Introduce JSON-based version 2 ACL syntax -- see below for discussion
* Implement account ACL authorization in TempAuth
X-Account-Access-Control Header
-------------------------------
Accounts now have a new privileged header to represent ACLs or any other
form of account-level access control. The value of the header is an opaque
string to be interpreted by the auth system, but it must be a JSON-encoded
dictionary. A reference implementation is given in TempAuth, with the
knowledge that historically other auth systems often use TempAuth as a
starting point.
The reference implementation describes three levels of account access:
"admin", "read-write", and "read-only". Adding new access control
features in a future patch (e.g. "write-only" account access) will
automatically be forward- and backward-compatible, due to the JSON
dictionary header format.
The privileged X-Account-Access-Control header may only be read or written
by a user with "swift_owner" status, traditionally the account owner but
now also any user on the "admin" ACL.
Access Levels:
Read-only access is intended to indicate to the auth system that this
list of identities can read everything (except privileged headers) in
the account. Specifically, a user with read-only account access can get
a list of containers in the account, list the contents of any container,
retrieve any object, and see the (non-privileged) headers of the
account, any container, or any object.
Read-write access is intended to indicate to the auth system that this
list of identities can read or write (or create) any container. A user
with read-write account access can create new containers, set any
unprivileged container headers, overwrite objects, delete containers,
etc. A read-write user can NOT set account headers (or perform any
PUT/POST/DELETE requests on the account).
Admin access is intended to indicate to the auth system that this list of
identities has "swift_owner" privileges. A user with admin account access
can do anything the account owner can, including setting account headers
and any privileged headers -- and thus changing the value of
X-Account-Access-Control and thereby granting read-only, read-write, or
admin access to other users.
The auth system is responsible for making decisions based on this header,
if it chooses to support its use. Therefore the above access level
descriptions are necessarily advisory only for other auth systems.
When setting the value of the header, callers are urged to use the new
format_acl() method, described below.
New ACL Format
--------------
The account ACLs introduce a new format for ACLs, rather than reusing the
existing format from X-Container-Read/X-Container-Write. There are several
reasons for this:
* Container ACL format does not support Unicode
* Container ACLs have a different structure than account ACLs
+ account ACLs have no concept of referrers or rlistings
+ accounts have additional "admin" access level
+ account access levels are structured as admin > rw > ro, which seems more
appropriate for how people access accounts, rather than reusing
container ACLs' orthogonal read and write access
In addition, the container ACL syntax is a bit arbitrary and highly custom,
so instead of parsing additional custom syntax, I'd rather propose a next
version and introduce a means for migration. The V2 ACL syntax has the
following benefits:
* JSON is a well-known standard syntax with parsers in all languages
* no artificial value restrictions (you can grant access to a user named
".rlistings" if you want)
* forward and backward compatibility: you may have extraneous keys, but
your attempt to parse the header won't raise an exception
I've introduced hooks in parse_acl and format_acl which currently default
to the old V1 syntax but tolerate the V2 syntax and can easily be flipped
to default to V2. I'm not changing the default or adding code to rewrite
V1 ACLs to V2, because this patch has suffered a lot of scope creep already,
but this seems like a sensible milestone in the migration.
TempAuth Account ACL Implementation
-----------------------------------
As stated above, core Swift is responsible for privileging the
X-Account-Access-Control header (making it only accessible to swift_owners),
for translating it to -sysmeta-* headers to trigger persistence by the
account server, and for including the header in the responses to requests
by privileged users. Core Swift puts no expectation on the *content* of
this header. Auth systems (including TempAuth) are responsible for
defining the content of the header and taking action based on it.
In addition to the changes described above, this patch defines a format
to be used by TempAuth for these headers in the common.middleware.acl
module, in the methods format_v2_acl() and parse_v2_acl(). This patch
also teaches TempAuth to take action based on the header contents. TempAuth
now sets swift_owner=True if the user is on the Admin ACL, authorizes
GET/HEAD/OPTIONS requests if the user is on any ACL, authorizes
PUT/POST/DELETE requests if the user is on the admin or read-write ACL, etc.
Note that the action of setting swift_owner=True triggers core Swift to
add or strip the privileged headers from the responses. Core Swift (not
the auth system) is responsible for that.
DocImpact: Documentation for the new ACL usage and format appears in
summary form in doc/source/overview_auth.rst, and in more detail in
swift/common/middleware/tempauth.py in the TempAuth class docstring.
I leave it to the Swift doc team to determine whether more is needed.
Change-Id: I836a99eaaa6bb0e92dc03e1ca46a474522e6e826
2013-11-13 20:55:14 +00:00
|
|
|
# For test coverage: verify that defensive coding does defend, in cases
|
|
|
|
# that shouldn't arise naturally
|
2016-04-27 13:31:11 -05:00
|
|
|
with self.assertRaises(ValueError):
|
|
|
|
# Container needs account
|
|
|
|
swift.proxy.controllers.base.get_cache_key(None, 'c')
|
|
|
|
|
|
|
|
with self.assertRaises(ValueError):
|
|
|
|
# Object needs account
|
|
|
|
swift.proxy.controllers.base.get_cache_key(None, 'c', 'o')
|
|
|
|
|
|
|
|
with self.assertRaises(ValueError):
|
|
|
|
# Object needs container
|
|
|
|
swift.proxy.controllers.base.get_cache_key('a', None, 'o')
|
Privileged acct ACL header, new ACL syntax, TempAuth impl.
* Introduce a new privileged account header: X-Account-Access-Control
* Introduce JSON-based version 2 ACL syntax -- see below for discussion
* Implement account ACL authorization in TempAuth
X-Account-Access-Control Header
-------------------------------
Accounts now have a new privileged header to represent ACLs or any other
form of account-level access control. The value of the header is an opaque
string to be interpreted by the auth system, but it must be a JSON-encoded
dictionary. A reference implementation is given in TempAuth, with the
knowledge that historically other auth systems often use TempAuth as a
starting point.
The reference implementation describes three levels of account access:
"admin", "read-write", and "read-only". Adding new access control
features in a future patch (e.g. "write-only" account access) will
automatically be forward- and backward-compatible, due to the JSON
dictionary header format.
The privileged X-Account-Access-Control header may only be read or written
by a user with "swift_owner" status, traditionally the account owner but
now also any user on the "admin" ACL.
Access Levels:
Read-only access is intended to indicate to the auth system that this
list of identities can read everything (except privileged headers) in
the account. Specifically, a user with read-only account access can get
a list of containers in the account, list the contents of any container,
retrieve any object, and see the (non-privileged) headers of the
account, any container, or any object.
Read-write access is intended to indicate to the auth system that this
list of identities can read or write (or create) any container. A user
with read-write account access can create new containers, set any
unprivileged container headers, overwrite objects, delete containers,
etc. A read-write user can NOT set account headers (or perform any
PUT/POST/DELETE requests on the account).
Admin access is intended to indicate to the auth system that this list of
identities has "swift_owner" privileges. A user with admin account access
can do anything the account owner can, including setting account headers
and any privileged headers -- and thus changing the value of
X-Account-Access-Control and thereby granting read-only, read-write, or
admin access to other users.
The auth system is responsible for making decisions based on this header,
if it chooses to support its use. Therefore the above access level
descriptions are necessarily advisory only for other auth systems.
When setting the value of the header, callers are urged to use the new
format_acl() method, described below.
New ACL Format
--------------
The account ACLs introduce a new format for ACLs, rather than reusing the
existing format from X-Container-Read/X-Container-Write. There are several
reasons for this:
* Container ACL format does not support Unicode
* Container ACLs have a different structure than account ACLs
+ account ACLs have no concept of referrers or rlistings
+ accounts have additional "admin" access level
+ account access levels are structured as admin > rw > ro, which seems more
appropriate for how people access accounts, rather than reusing
container ACLs' orthogonal read and write access
In addition, the container ACL syntax is a bit arbitrary and highly custom,
so instead of parsing additional custom syntax, I'd rather propose a next
version and introduce a means for migration. The V2 ACL syntax has the
following benefits:
* JSON is a well-known standard syntax with parsers in all languages
* no artificial value restrictions (you can grant access to a user named
".rlistings" if you want)
* forward and backward compatibility: you may have extraneous keys, but
your attempt to parse the header won't raise an exception
I've introduced hooks in parse_acl and format_acl which currently default
to the old V1 syntax but tolerate the V2 syntax and can easily be flipped
to default to V2. I'm not changing the default or adding code to rewrite
V1 ACLs to V2, because this patch has suffered a lot of scope creep already,
but this seems like a sensible milestone in the migration.
TempAuth Account ACL Implementation
-----------------------------------
As stated above, core Swift is responsible for privileging the
X-Account-Access-Control header (making it only accessible to swift_owners),
for translating it to -sysmeta-* headers to trigger persistence by the
account server, and for including the header in the responses to requests
by privileged users. Core Swift puts no expectation on the *content* of
this header. Auth systems (including TempAuth) are responsible for
defining the content of the header and taking action based on it.
In addition to the changes described above, this patch defines a format
to be used by TempAuth for these headers in the common.middleware.acl
module, in the methods format_v2_acl() and parse_v2_acl(). This patch
also teaches TempAuth to take action based on the header contents. TempAuth
now sets swift_owner=True if the user is on the Admin ACL, authorizes
GET/HEAD/OPTIONS requests if the user is on any ACL, authorizes
PUT/POST/DELETE requests if the user is on the admin or read-write ACL, etc.
Note that the action of setting swift_owner=True triggers core Swift to
add or strip the privileged headers from the responses. Core Swift (not
the auth system) is responsible for that.
DocImpact: Documentation for the new ACL usage and format appears in
summary form in doc/source/overview_auth.rst, and in more detail in
swift/common/middleware/tempauth.py in the TempAuth class docstring.
I leave it to the Swift doc team to determine whether more is needed.
Change-Id: I836a99eaaa6bb0e92dc03e1ca46a474522e6e826
2013-11-13 20:55:14 +00:00
|
|
|
|
|
|
|
def test_stripping_swift_admin_headers(self):
|
|
|
|
# Verify that a GET/HEAD which receives privileged headers from the
|
|
|
|
# account server will strip those headers for non-swift_owners
|
|
|
|
|
|
|
|
headers = {
|
|
|
|
'x-account-meta-harmless': 'hi mom',
|
|
|
|
'x-account-meta-temp-url-key': 's3kr1t',
|
|
|
|
}
|
|
|
|
controller = proxy_server.AccountController(self.app, 'acct')
|
|
|
|
|
|
|
|
for verb in ('GET', 'HEAD'):
|
|
|
|
for env in ({'swift_owner': True}, {'swift_owner': False}):
|
|
|
|
req = Request.blank('/v1/acct', environ=env)
|
|
|
|
controller.GETorHEAD_base = lambda *_: Response(
|
|
|
|
headers=headers, environ={
|
|
|
|
'PATH_INFO': '/acct',
|
|
|
|
'REQUEST_METHOD': verb,
|
|
|
|
})
|
|
|
|
method = getattr(controller, verb)
|
|
|
|
resp = method(req)
|
|
|
|
self.assertEqual(resp.headers.get('x-account-meta-harmless'),
|
|
|
|
'hi mom')
|
|
|
|
privileged_header_present = (
|
|
|
|
'x-account-meta-temp-url-key' in resp.headers)
|
|
|
|
self.assertEqual(privileged_header_present, env['swift_owner'])
|
|
|
|
|
2016-01-22 05:19:06 +00:00
|
|
|
def test_response_code_for_PUT(self):
|
|
|
|
PUT_TEST_CASES = [
|
2016-02-22 16:10:09 +09:00
|
|
|
((201, 201, 201), 201),
|
|
|
|
((201, 201, 404), 201),
|
|
|
|
((201, 201, 503), 201),
|
|
|
|
((201, 404, 404), 404),
|
|
|
|
((201, 404, 503), 503),
|
|
|
|
((201, 503, 503), 503),
|
2016-01-22 05:19:06 +00:00
|
|
|
((404, 404, 404), 404),
|
|
|
|
((404, 404, 503), 404),
|
|
|
|
((404, 503, 503), 503),
|
|
|
|
((503, 503, 503), 503)
|
|
|
|
]
|
|
|
|
self._assert_responses('PUT', PUT_TEST_CASES)
|
|
|
|
|
|
|
|
def test_response_code_for_DELETE(self):
|
|
|
|
DELETE_TEST_CASES = [
|
|
|
|
((204, 204, 204), 204),
|
|
|
|
((204, 204, 404), 204),
|
|
|
|
((204, 204, 503), 204),
|
|
|
|
((204, 404, 404), 404),
|
|
|
|
((204, 404, 503), 503),
|
|
|
|
((204, 503, 503), 503),
|
|
|
|
((404, 404, 404), 404),
|
|
|
|
((404, 404, 503), 404),
|
|
|
|
((404, 503, 503), 503),
|
|
|
|
((503, 503, 503), 503)
|
|
|
|
]
|
|
|
|
self._assert_responses('DELETE', DELETE_TEST_CASES)
|
|
|
|
|
|
|
|
def test_response_code_for_POST(self):
|
|
|
|
POST_TEST_CASES = [
|
|
|
|
((204, 204, 204), 204),
|
|
|
|
((204, 204, 404), 204),
|
|
|
|
((204, 204, 503), 204),
|
|
|
|
((204, 404, 404), 404),
|
|
|
|
((204, 404, 503), 503),
|
|
|
|
((204, 503, 503), 503),
|
|
|
|
((404, 404, 404), 404),
|
|
|
|
((404, 404, 503), 404),
|
|
|
|
((404, 503, 503), 503),
|
|
|
|
((503, 503, 503), 503)
|
|
|
|
]
|
|
|
|
self._assert_responses('POST', POST_TEST_CASES)
|
|
|
|
|
|
|
|
|
|
|
|
@patch_policies(
|
|
|
|
[StoragePolicy(0, 'zero', True, object_ring=FakeRing(replicas=4))])
|
|
|
|
class TestAccountController4Replicas(TestAccountController):
|
|
|
|
def setUp(self):
|
|
|
|
self.app = proxy_server.Application(
|
|
|
|
None,
|
|
|
|
FakeMemcache(),
|
|
|
|
account_ring=FakeRing(replicas=4),
|
|
|
|
container_ring=FakeRing(replicas=4))
|
|
|
|
|
|
|
|
def test_response_code_for_PUT(self):
|
|
|
|
PUT_TEST_CASES = [
|
2016-02-22 16:10:09 +09:00
|
|
|
((201, 201, 201, 201), 201),
|
|
|
|
((201, 201, 201, 404), 201),
|
|
|
|
((201, 201, 201, 503), 201),
|
2016-04-27 16:59:00 -05:00
|
|
|
((201, 201, 404, 404), 201),
|
|
|
|
((201, 201, 404, 503), 201),
|
|
|
|
((201, 201, 503, 503), 201),
|
2016-02-22 16:10:09 +09:00
|
|
|
((201, 404, 404, 404), 404),
|
2016-04-27 16:59:00 -05:00
|
|
|
((201, 404, 404, 503), 404),
|
2016-02-22 16:10:09 +09:00
|
|
|
((201, 404, 503, 503), 503),
|
|
|
|
((201, 503, 503, 503), 503),
|
2016-01-22 05:19:06 +00:00
|
|
|
((404, 404, 404, 404), 404),
|
|
|
|
((404, 404, 404, 503), 404),
|
2016-04-27 16:59:00 -05:00
|
|
|
((404, 404, 503, 503), 404),
|
2016-01-22 05:19:06 +00:00
|
|
|
((404, 503, 503, 503), 503),
|
|
|
|
((503, 503, 503, 503), 503)
|
|
|
|
]
|
|
|
|
self._assert_responses('PUT', PUT_TEST_CASES)
|
|
|
|
|
|
|
|
def test_response_code_for_DELETE(self):
|
|
|
|
DELETE_TEST_CASES = [
|
|
|
|
((204, 204, 204, 204), 204),
|
|
|
|
((204, 204, 204, 404), 204),
|
|
|
|
((204, 204, 204, 503), 204),
|
2016-04-27 16:59:00 -05:00
|
|
|
((204, 204, 404, 404), 204),
|
|
|
|
((204, 204, 404, 503), 204),
|
|
|
|
((204, 204, 503, 503), 204),
|
2016-01-22 05:19:06 +00:00
|
|
|
((204, 404, 404, 404), 404),
|
2016-04-27 16:59:00 -05:00
|
|
|
((204, 404, 404, 503), 404),
|
2016-01-22 05:19:06 +00:00
|
|
|
((204, 404, 503, 503), 503),
|
|
|
|
((204, 503, 503, 503), 503),
|
|
|
|
((404, 404, 404, 404), 404),
|
|
|
|
((404, 404, 404, 503), 404),
|
2016-04-27 16:59:00 -05:00
|
|
|
((404, 404, 503, 503), 404),
|
2016-01-22 05:19:06 +00:00
|
|
|
((404, 503, 503, 503), 503),
|
|
|
|
((503, 503, 503, 503), 503)
|
|
|
|
]
|
|
|
|
self._assert_responses('DELETE', DELETE_TEST_CASES)
|
|
|
|
|
|
|
|
def test_response_code_for_POST(self):
|
|
|
|
POST_TEST_CASES = [
|
|
|
|
((204, 204, 204, 204), 204),
|
|
|
|
((204, 204, 204, 404), 204),
|
|
|
|
((204, 204, 204, 503), 204),
|
2016-04-27 16:59:00 -05:00
|
|
|
((204, 204, 404, 404), 204),
|
|
|
|
((204, 204, 404, 503), 204),
|
|
|
|
((204, 204, 503, 503), 204),
|
2016-01-22 05:19:06 +00:00
|
|
|
((204, 404, 404, 404), 404),
|
2016-04-27 16:59:00 -05:00
|
|
|
((204, 404, 404, 503), 404),
|
2016-01-22 05:19:06 +00:00
|
|
|
((204, 404, 503, 503), 503),
|
|
|
|
((204, 503, 503, 503), 503),
|
|
|
|
((404, 404, 404, 404), 404),
|
|
|
|
((404, 404, 404, 503), 404),
|
2016-04-27 16:59:00 -05:00
|
|
|
((404, 404, 503, 503), 404),
|
2016-01-22 05:19:06 +00:00
|
|
|
((404, 503, 503, 503), 503),
|
|
|
|
((503, 503, 503, 503), 503)
|
|
|
|
]
|
|
|
|
self._assert_responses('POST', POST_TEST_CASES)
|
|
|
|
|
2013-03-30 15:55:29 +03:00
|
|
|
|
Fix up get_account_info and get_container_info
get_account_info used to work like this:
* make an account HEAD request
* ignore the response
* get the account info by digging around in the request environment,
where it had been deposited by elves or something
Not actually elves, but the proxy's GETorHEAD_base method would take
the HEAD response and cache it in the response environment, which was
the same object as the request environment, thus enabling
get_account_info to find it.
This was extraordinarily brittle. If a WSGI middleware were to
shallow-copy the request environment, then any middlewares to its left
could not use get_account_info, as the left middleware's request
environment would no longer be identical to the response environment
down in GETorHEAD_base.
Now, get_account_info works like this:
* make an account HEAD request.
* if the account info is in the request environment, return it. This
is an optimization to avoid a double-set in memcached.
* else, compute the account info from the response headers, store it
in caches, and return it.
This is much easier to think about; get_account_info can get and cache
account info all on its own; the cache check and cache set are right
next to each other.
All the above is true for get_container_info as well.
get_info() is still around, but it's just a shim. It was trying to
unify get_account_info and get_container_info to exploit the
commonalities, but the number of times that "if container:" showed up
in get_info and its helpers really indicated that something was
wrong. I'd rather have two functions with some duplication than one
function with no duplication but a bunch of "if container:" branches.
Other things of note:
* a HEAD request to a deleted account returns 410, but
get_account_info would return 404 since the 410 came from the
account controller *after* GETorHEAD_base ran. Now
get_account_info returns 410 as well.
* cache validity period (recheck_account_existence and
recheck_container_existence) is now communicated to
get_account_info via an X-Backend header. This way,
get_account_info doesn't need a reference to the
swift.proxy.server.Application object.
* both logged swift_source values are now correct for
get_container_info calls; before, on a cold cache,
get_container_info would call get_account_info but not pass along
swift_source, resulting in get_account_info logging "GET_INFO" as
the source. Amusingly, there was a unit test asserting this bogus
behavior.
* callers that modify the return value of get_account_info or of
get_container_info don't modify what's stored in swift.infocache.
* get_account_info on an account that *can* be autocreated but has
not been will return a 200, same as a HEAD request. The old
behavior was a 404 from get_account_info but a 200 from
HEAD. Callers can tell the difference by looking at
info['account_really_exists'] if they need to know the difference
(there is one call site that needs to know, in container
PUT). Note: this is for all accounts when the proxy's
"account_autocreate" setting is on.
Change-Id: I5167714025ec7237f7e6dd4759c2c6eb959b3fca
2016-02-11 15:51:45 -08:00
|
|
|
@patch_policies([StoragePolicy(0, 'zero', True, object_ring=FakeRing())])
|
|
|
|
class TestGetAccountInfo(unittest.TestCase):
|
|
|
|
def setUp(self):
|
|
|
|
self.app = proxy_server.Application(
|
|
|
|
None, FakeMemcache(),
|
|
|
|
account_ring=FakeRing(), container_ring=FakeRing())
|
|
|
|
|
|
|
|
def test_get_deleted_account_410(self):
|
|
|
|
resp_headers = {'x-account-status': 'deleted'}
|
|
|
|
|
|
|
|
req = Request.blank('/v1/a')
|
|
|
|
with mock.patch('swift.proxy.controllers.base.http_connect',
|
|
|
|
fake_http_connect(404, headers=resp_headers)):
|
|
|
|
info = get_account_info(req.environ, self.app)
|
|
|
|
self.assertEqual(410, info.get('status'))
|
|
|
|
|
|
|
|
|
2013-03-30 15:55:29 +03:00
|
|
|
if __name__ == '__main__':
|
|
|
|
unittest.main()
|