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 http://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 mailto: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 <http://www.linaro.org>> │ Open source software for ARM SoCs _______________________________________________ Lava-devel mailing list Lava-devel@lists.lavasoftware.org <mailto: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