Correct workaround in OSSN-0013
The workaround previously described in OSSN-0013 was not correct due to a misunderstanding in the behavior of the original bug. This update adds a workaround that has been tested in Havana, and it also provides a more clear description about Glance's broken behavior with regards to processing property protections rules. Related-Bug: #1271426 Change-Id: Ice8f6d31345c308f09ee14b55053d205d9f57e69
This commit is contained in:
Nathan Kinder
parent
29305c9fe5
commit
5f5202470c
102
notes/OSSN-0013
102
notes/OSSN-0013
|
|
@ -12,65 +12,71 @@ Glance, Folsom, Grizzly
|
|||
|
||||
### Discussion ###
|
||||
Glance property protections limit the users who can perform CRUD operations on
|
||||
a Glance property to those in specific roles. If there is a specific rule that
|
||||
would reject an action and a less specific rule that comes after that accepts
|
||||
the action, then the action is accepted even though one may expect it to be
|
||||
rejected.
|
||||
a Glance property to those in specific roles. When the property protections
|
||||
rules are processed in the Folsom and Grizzly OpenStack releases, a matching
|
||||
rule will only stop the processing of subsequent rules if it authorizes the
|
||||
attempted action. If there is a matching rule that would reject an action that
|
||||
is followed by another matching rule that would accept the action, then the
|
||||
action is accepted even though one may expect it to be rejected.
|
||||
|
||||
In the following policy-protections.conf example, the desired result is to
|
||||
restrict 'update' and 'delete' permissions for any property beginning with
|
||||
'provider_' to only users with the 'admin' role.
|
||||
|
||||
--- begin example property-protections.conf snippet ---
|
||||
[^provider_.*$]
|
||||
create = admin
|
||||
read = admin,_member_
|
||||
update = admin
|
||||
delete = admin
|
||||
|
||||
[.*]
|
||||
create = _member_
|
||||
read = _member_
|
||||
update = _member_
|
||||
delete = _member_
|
||||
--- end example property-protections.conf snippet ---
|
||||
|
||||
Due to the way that the rules are processed in the Folsom and Grizzly OpenStack
|
||||
releases, the admin restriction for properties beginning with 'provider_' is
|
||||
nullified by the '.*' permissions since it also matches the same properties.
|
||||
This results in all users with the '_member_' role being allowed the 'create',
|
||||
'update', and 'delete' permissions on properties beginning with 'provider_',
|
||||
which is not what was intended.
|
||||
|
||||
This bug only affects the use of user-roles in Glance. It does not occur when
|
||||
policies are used to determine property protections.
|
||||
|
||||
In the following policy-protections.conf example, the desired result is to
|
||||
restrict 'update' and 'delete' permissions for 'foo_property' to only users
|
||||
with the 'admin' role.
|
||||
|
||||
--- Begin Example ---
|
||||
/etc/glance/property-protections.conf
|
||||
[^foo_property$]
|
||||
create = @
|
||||
read = @
|
||||
update = admin
|
||||
delete = admin
|
||||
|
||||
[.*]
|
||||
create = @
|
||||
read = @
|
||||
update = @
|
||||
delete = @
|
||||
--- End Example ---
|
||||
|
||||
Due to the order that the rules are applied in the Folsom and Grizzly OpenStack
|
||||
releases, the admin restriction for 'foo_property' is nullified by the '.*'
|
||||
permissions. This results in all roles being allowed the 'update' and 'delete'
|
||||
permissions on 'foo_property', which is not what was intended.
|
||||
|
||||
### Recommended Actions ###
|
||||
This issue has been fixed in Havana (Glance 2013.2.2) and subsequent releases.
|
||||
This issue has been fixed in Havana (Glance 2013.2.2) and subsequent releases
|
||||
by changing the property protections rule processing to stop at the first rule
|
||||
that matches the property, even if it does not allow the attempted action.
|
||||
|
||||
Users of affected releases should review and reorder the entries in
|
||||
property-protections.conf to place the most open permissions at the start of
|
||||
the configuration and more restrictive ones at the end, as demonstrated below.
|
||||
Users of affected releases should avoid using multiple rules that would match
|
||||
the same property. Specifically, wildcard rules should be avoided unless they
|
||||
are the most restricive rules defined.
|
||||
|
||||
--- Begin Example ---
|
||||
/etc/Glance/property-protections.conf
|
||||
[.*]
|
||||
create = @
|
||||
read = @
|
||||
update = @
|
||||
delete = @
|
||||
If a permissive rule is needed that is intended to match all properties that
|
||||
are not matched by other rules, a carefully crafted regular expression should
|
||||
be used instead of a wildcard as demonstrated below.
|
||||
|
||||
[^foo_property$]
|
||||
create = @
|
||||
read = @
|
||||
--- begin example property-protections.conf snippet ---
|
||||
[^provider_.*$]
|
||||
create = admin
|
||||
read = admin,_member_
|
||||
update = admin
|
||||
delete = admin
|
||||
--- End Example ---
|
||||
|
||||
In the above example, '.*' and 'foo_property' entries in the protections file
|
||||
have been reversed, ensuring that the more restrictive permissions required for
|
||||
'foo_property' are applied after the wider '.*' permissions and assuring that
|
||||
'update' and 'delete' operations are restricted to only users with in the
|
||||
'admin' role.
|
||||
[^((?!provider_).)*$]
|
||||
create = _member_
|
||||
read = _member_
|
||||
update = _member_
|
||||
delete = _member_
|
||||
--- end example property-protections.conf snippet ---
|
||||
|
||||
In the above example, 'create', 'update', and 'delete' operations are only
|
||||
allowed for users with the '_member_' role for properties that do not begin
|
||||
with 'provider_'.
|
||||
|
||||
Configuration files with multiple property protection entries set should be
|
||||
tested to ensure that CRUD actions are constrained in the way the administrator
|
||||
|
|
|
|||
Loading…
Reference in New Issue