cubicweb #3154558 [security] rdefs using default read permissions: just do nothing [open]
Because:
| |
priority | normal |
---|---|
type | enhancement |
done in | <not specified> |
load | 1.000 |
load left | 1.000 |
closed by | <not specified> |
patch | [security] when checking an rdef `read security groups`, do nothing if they are the default [rejected] |
similar entities
- cubicweb #1698245 Convert __message to _cwmsgid to increase security
- cubicweb #511718 explain why rql expr insertion doesn't work to ease security debugging
- TheCubicWebBook #656194 CW Administration: how to give dynamic permissions
- cubicweb #1346310 Add `Secure` attribute to cookie when navigating on https
- cubicweb #1381390 Implement HTTP Strict Transport Security for https
[see all]
Comments
-
2013/09/19 08:23, written by acampeas
- creates an Affaire
- creates a Societe and links to the Affaire through "concerne"
- wants to set the "sujet" attribute of the Societe
- the querier performs a read group check on the "sujet" attribute
* since the default sec on attributes is ('managers', 'users', 'guests') it passes (!)
* later, the rqlrewriter interpolates the rql expressions, hence since the user owns both ends of the "concerne" relation it works ok
- when writing a schema like this, the typical end user NEVER thinks she just gave ('managers', 'users', 'guests') group permissions to the Societe attributes,
- instead she believes the permission rule at entity level controls the whole entity (that is, attributes-security), unless a specific attribute permission rule is written
-
2013/09/19 09:48, written by acampeas
-
2013/09/28 10:24, written by acampeas
-
2014/08/01 13:23, written by acampeas
add commentFirst problem seen while implementing this: the test unittest_security.test_update_rql_permission breaks.
It works on the following (reduced) schema, with read perms shown:
We have a scenario where a "user" (belonging only to the users group):
As of today it all works. Let's detail point 3 security check:
It think this way of life is a pb., because:
I have the following scenario to implement: a "readonly" profile. Unfortunately, it cannot be made to work (with a "readonly" group at least) unless every attribute of every entity type is explicitly given a non-default, e.g. ('managers', 'users', 'guests', 'readonly') rule. Which is a bit unfriendly...
Opinions ?
Well, doing nothind wrt rdefs read permissions == default read permissions "just works".
this actually must be extended to write security checks
As of 01-08-2014, the need rises again. Let's do it !