Hi all,

I wanted to share a few new technical details from the LAVA design meeting today regarding LAVA permissions revamp.
Some highlights, concerns and use cases include:

* We will use django's native permissions model with the addition of custom models to enable per-object level permissions.
* DeviceType will also become 'restricted', i.e. permissions will also be available for use in this model.
* Permission inheritance: TestJob permissions will also check for more restricting permissions of Device and DeviceType. Same goes for Device permissions: we will always check for more restricting permissions in DeviceType.
* For now, these permission levels will be included but this is susceptible to change/suggestions: 'view', 'add', 'change' (delete should be available only to superuser for any model).
* This will be inline with django's authorization model already in place: if a user has global permission over some objects, we can ignore the per-object level permissions (or maybe decide to do the other way around).
* It's a good idea to limit the permission to group entity only and control everything on the group level, but this might prove difficult because of the AnonymousUser permissions which will also be necessary (see use cases below).
django-restricted-resource library will be removed, alongside the need for user, group and is_public fields.
* Various fields used for authorization will be removed, including but not limited to: DeviceType.owners_only, Device.visibility, Device.viewing_groups

Use cases:
* When creating the device type for example, we want it to be completely visible to everybody (even non-authenticated user) because we want first-time users to have the least amount of setup possible, but we also want the possibility to limit this device type to everybody.
* There's a need sometimes to have a testjob with a restricted visibility, even though the device and device type are completely visible. This means that this functionality should be visible in the test submission api/view as well.
* Need to make sure that every change to permissions is logged in the change history.

If I've skipped anything please let me know. Also any new ideas/thoughts are highly appreciated.

Cheers,

On 1/29/19 9:55 AM, Stevan Radakovic wrote:
Hi Remi,

Nice breakdown, thanks.
Exactly, that is the idea behind the "cached" value for device types mentioned in the first email.
I will share some more technical details in the design meeting tomorrow.

Cheers,


On 1/28/19 5:31 PM, Remi Duraffort wrote:
Hello Stevan,

I'm wondering if we should not take this opportunity to refactor a bit further the authorization model.

I looked at validation.linaro.org and found that if we exclude retired devices and hidden device-types, we have:
* public devices:
  * 4 owned by users
  * 26 owned by groups
* private devices:
  * 0 owned by users
  * 26 owned by groups
device_type.owners_only is only set for some of the private devices, owned by groups.

Any idea would be to add a read-only "groups" field to the device_type. This field will be updated automatically when a device groups is changed. When viewing the device-type page, we can then just filter by groups.


Rgds


Le mer. 23 janv. 2019 à 15:46, Stevan Radakovic <stevan.radakovic@linaro.org> a écrit :
Dear all,

I'd like to propose a couple of designs and thoughts on the
authorization subject and get the feedback from the community and LAVA
core team in the process. Link to the issue:
https://git.lavasoftware.org/lava/lava/issues/201

As stated before, the main reason behind the authorization revamp is
that checking the device types accessible to the specific user is not
optimized in the slightest and does not scale. The specific device type
authorization is in some cases also used in device authorization which
also adds to the complexity.

Now, while the problems at hand can be addressed directly to mitigate
the scalability, it'd be also smart to do something about the
django-restricted-resource library. Why? Well, django already has a
perfectly sound authentication model which can also be used for a
per-object access with a little effort so essentially it means much less
complexity, code and all the benefits that go along with these.
There's two approaches here: write our own authentication backend and
use already existing django-guardian project (available as debian
package) which is well maintained. I think having our own backend is
slightly better solution just because there's no need to add more
complexity with a third-party package then we need and it seems to me
that our needs can be addressed with a small code base.

Once that's in place, the proposal is to address the device-type
authorization with a cached value (currently, if a user can access any
device from a specific device type, it can access the device type as
well), meaning that we store the device-type visibility as a separate
permission automagically so that the check for that can be performed
without checking all the device permission in that device type. We'd
also remove the complexity in the various frontend views regarding the
device/device type visibility without changing the behavior.

All comments/ideas welcome.

Cheers,

--
Stevan Radaković | LAVA Engineer
Linaro.org <www.linaro.org> │ Open source software for ARM SoCs


_______________________________________________
Lava-devel mailing list
Lava-devel@lists.lavasoftware.org
https://lists.lavasoftware.org/mailman/listinfo/lava-devel


--
Rémi Duraffort
LAVA Team, Linaro

-- 
Stevan Radaković | LAVA Engineer
Linaro.org <www.linaro.org> │ Open source software for ARM SoCs


-- 
Stevan Radaković | LAVA Engineer
Linaro.org <www.linaro.org> │ Open source software for ARM SoCs