Comment 11 for bug 1271426

The workaround proposed in OSSN-0013 does not work (tested against 2013.2):

"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."

The implementation (in 2013.2) will stop the processing of rules at the first positive (authorized) match. This means by placing the most generic rule first, all following rules will be ignored.

One possible workaround would be to replace the generic rule [.*] by a very complex regex crafted in a way to NOT match all the other rules protecting your properties.

As explained above, the faulty implementation WON'T stop processing the rules if a matching rule (property regex) is found. You therefore don't want a protected property to be authorized by a wildcard. Hopefully, it is made so if NO match is found, the property is still protected.

Example of such workaround:

[^provider_.*$]
create = admin
read = _member_
update = admin
delete = admin

# Note the trailing $ to make sure all the string is matched
[^((?!provider_).)*$]
create = _member_
read = _member_
update = _member_
delete = _member_