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