Most of them are outdated , but provide historical design context.
They are not user documentation and should not be treated as such.
Documentation is available here.
User Portal Permissions
This page details how the User Portal decides what objects to display, specifically in relation to create permissions.
- Name: Allon Mureinik
- Email: email@example.com
- Status: Released in oVirt 3.1
Query Permissions and Integration with MLA
For each query the engine will manage
queryType, which can be either an Admin query or a User query. Admin query means only admins can execute the query, while User query means that any user can execute the query (administrators included). In addition to the
queryType a parameter, an
isFiltered parameter will be added to the
VdcQueryParametersBase class. This parameter will govern if the query is executed in filtered mode (and should return only the objects the user has user permissions on) or not (and as such should return all the objects). The default is that
isFiltered is set to
false, due to backwards compatibility considerations.
Permission checking will be done in two levels:
- Authorization - before executing the query: validating a user is an administrator (i.e., has at least one administrator role) if the query is an Admin query or if
isFilteredis set to
- Filtering - as part of the query execution: joining the "business logic" of the query to a permissions view, providing a single point of entry to managing permission logic.
queryType will be added to the enum. Most queries are not available to users so the default will be
From now on, it will be possible to specify if the query should be executed in admin or in filtered mode. The default will be to execute as admin, for backwards compatibility reasons.
Running a Query
In case of an admin query (be it due to the query's internal type or to a request to run as an admin), the query will perform a minimal authorization check to see if the user may execute such queries.
Each method used by a user query will be overloaded with two additional parameters -
isFiltered. E.g., we would like to have a filtered version of
GetVmInterfacesByVmIdQuery, which uses
VmNetworkInterfaceDAO.getAllForVm(Guid vmID), so we will overload this method and create
VmNetworkInterfaceDAO.getAllForVm(Guid vmID, Guid userID, boolean isFiltered).
Hibernate DAO implementations
Currently, will not be supported. If necessary, an additional method that throws
UnsupportedOperationException, and a test that verifies this exception is thrown so when the Hibernate DAO will be implemented that test will break, and the implementor will remember to implement this method too.
A set of n flat views (one per entity type) will be created. The view will hold the
entity_id and fields will implement the flattened logic of permissions. E.g., if it's decided that permissions on pool grant read permissions on the VMs inside it, this will be exposed in the
vm_permissions_view view. Each query implementation will be responsible for joining with the appropriate permissions view. Thus, permission-checking logic will only be implemented in a single place (per type, unfortunately) instead of inside each query.
Each stored procedure used by a user query will have two parameters added to it -
user_id (UUID) and
Today, the User Portal exposes all the objects under an entity if any permission is given on that entity or on the reflecting entities (add link to explanation what is reflecting entities). This behaviour is correct for "manipulate" and "use" permission, but not for "create" permissions. E.g. If a user has the permissions to create a VM in a cluster, he should not be able to see all the VMs in that cluster.
In the suggested solution, an additional column,
boolean) will be added to the
roles_groups table. Only action groups with
allows_viewing_children=true will provide permissions on the objects contained in the object they are granted on.
Following is a detailed description of the behavior for each entity type.
- Data Center - Create VM/Template permission will not grant the ability to view VMs/Templates in the DC.
- Cluster - Create VM/Template permission will not grant the ability to view VMs/Templates in the cluster.
- Storage Domain - Create VM/Template/Disk permission will not grant the ability to view objects contained in the storage domain.
Two new predefined roles should be added - VM Creator and Template Creator, which only contain the action groups for adding VMs/Templates, respectively, and do not allow users to manipulate existing entities. These new roles will be the way administrators will grant their users the ability to create new VMs/Templates without exposing existing ones. For disks, the existing role Disk Creator will be used.
For the modification of an existing templates/vms/disks the VM ADMIN, TEMPLATE ADMIN and DISK ADMIN roles should be given to a user who issues a CreateVMTempalteCommand on the template he created.
No new entities are required for this feature.
No new entities are required for this feature.
See Inheriting Permissions.
The three new predefined roles should be created.
Adding a VM
- The admin grants the VM Creator permission to a user on a host/cluster
- The user can create a new VM on the host/cluster
- Once the user creates the VM, he becomes a VM Operator on this VM
No new events are added.
Dependencies / Related Features and Projects
As part of the user level queries changes, we also added user-level API capabilities to the REST API. Before these changes, only administrators could login to the API. Now, you can logic as a regular user as well, by specifying the "filter: true" HTTP header. For example, as a user, in order to get all your VMs through the API you can do the following:
curl http://engine-address:engine-port/api/vms -u "user@domain":password -H
The following endpoints are supported:
Documentation / External references
Writing A New User Query
- Should Create Host permissions be inherited for viewing?
- Should we grant VM/Template Creator to any user who is a VM/Template Admin?
- How do Disk Permissions integrate with this solution?