Univention Bugzilla – Bug 30484
Access to school wizards not configurable
Last modified: 2013-06-07 21:40:32 CEST
The UMC policy for accessing the school wizards for adding users, computers, groups and schools is too broad. When a school admin user is logged in, the wizards figure out to which school this user belongs and limit his ability to create new objects to his own school. The only problem is that he is still allowed to create new schools! No administrator would allow school admins to do that. It would be very helpful if UMC access to the different wizards would be configurable on a per wizard basis.
If the operation sets are configured properly, it is already possible to configure on a per wizard basis. Despite that, with default settings the create_ou wizard should not be available for school admins.
Workaround on DC master for creating operation set for "add user" module: . /usr/share/univention-lib/umc.sh umc_operation_create "schoolwizards-user" "User school wizard" \ "schoolwizards/users" "schoolwizards/*" Names of all four available flavours: - schoolwizards/users - schoolwizards/classes - schoolwizards/computers - schoolwizards/schools
A customer created his own UMC operation set let like this: umc_operation_create "schoolwizards-user" "User school wizard" "" schoolwizards/users schoolwizards/classes schoolwizards/computers After assigning the new operation set to ucsschool-umc-admins-default by replacing the schoolwizards-all, the following two problems appear: 1. The school wizard is still visible although just users, classes and computers should be accessible 2. When opening on of the modules with a regular UCS@school admin user (OU teacher who is a member of admins-OU) an error message is displayed stating: Forbidden management-console-web-server.log: 27.12.12 16:42:13.114 MAIN ( PROCESS ) : CPCommand (192.168.0.161:40323) response status code: 403 27.12.12 16:42:13.114 MAIN ( PROCESS ) : CPCommand (192.168.0.161:40323) response message: Forbidden 27.12.12 16:42:13.115 MAIN ( PROCESS ) : CPCommand (192.168.0.161:40323) response result: None
(In reply to comment #3) > A customer created his own UMC operation set let like this: > > umc_operation_create "schoolwizards-user" "User school wizard" "" > schoolwizards/users schoolwizards/classes schoolwizards/computers > > After assigning the new operation set to ucsschool-umc-admins-default by > replacing the schoolwizards-all, the following two problems appear: > 1. The school wizard is still visible although just users, classes and > computers should be accessible > 2. When opening on of the modules with a regular UCS@school admin user (OU > teacher who is a member of admins-OU) an error message is displayed stating: > Forbidden > > management-console-web-server.log: > 27.12.12 16:42:13.114 MAIN ( PROCESS ) : CPCommand > (192.168.0.161:40323) response status code: 403 > 27.12.12 16:42:13.114 MAIN ( PROCESS ) : CPCommand > (192.168.0.161:40323) response message: Forbidden > 27.12.12 16:42:13.115 MAIN ( PROCESS ) : CPCommand > (192.168.0.161:40323) response result: None The format of umc_operation_create is: umc_operation_create <OperationSetName> <OperationSetDescription> \ <Flavor> <operation1> [<operation2>...] As mentioned in comment 2, the flavors for this module are: schoolwizards/users schoolwizards/classes schoolwizards/computers schoolwizards/schools The visibility can be controlled only by the flavor in this case. As soon as any command for a module (and its flavor) is accessible, the module will be shown in UMC. In the above mentioned case, no flavor is specified (→ "") and thus all modules are visible. The last three arguments are the UMCP commands that are allowed, i.e., other commands (e.g. schoolwizards/schools) cannot be accessed and thus result in a 403 (=forbidden) error. The solution for the described case would be to create one operation set per module where the visibility is controlled via the flavor option (operation sets can also be created via UMC → LDAP directory → univention/UMC/operations) and to aggregate the three wizards in one UMC-Policy: for flavor in users classes computers schools; do umc_operation_create schoolwizards-$flavor \ "$flavor school wizard" \ "schoolwizards/$flavor" \ "schoolwizards/*" done This works for me w.r.t. the visibility. However, the wizards themselves do not respect the flavors when sending UMCP commands → this is a wizards bug and needs to be adjusted in the JavaScript code.
(In reply to comment #4) > ... > for flavor in users classes computers schools; do > umc_operation_create schoolwizards-$flavor \ > "$flavor school wizard" \ > "schoolwizards/$flavor" \ > "schoolwizards/*" > done This would be nice to include in the join script of the wizards module.
(In reply to comment #4) > ... > This works for me w.r.t. the visibility. However, the wizards themselves do not > respect the flavors when sending UMCP commands → this is a wizards bug and > needs to be adjusted in the JavaScript code. Once again, due to an error with the handling of flavors, the access to the wizards cannot be configured currently.
(In reply to comment #6) > (In reply to comment #4) > > ... > > This works for me w.r.t. the visibility. However, the wizards themselves do not > > respect the flavors when sending UMCP commands → this is a wizards bug and > > needs to be adjusted in the JavaScript code. > > Once again, due to an error with the handling of flavors, the access to the > wizards cannot be configured currently. As a workaround it's possible to remove the flavor tag with the id of the unwanted wizard, i.e. "schoolwizards/schools", from /usr/share/univention-management-console/modules/schoolwizards.xml. This disables the wizard for all users till this bug is fixed.
The behavior has been adapted: * The flavor is now always send along with every umcp-command * For each flavor there is a operation set now * The schoolwizards-all operation set has been removed
(In reply to comment #8) > The behavior has been adapted: > * The flavor is now always send along with every umcp-command > * For each flavor there is a operation set now > * The schoolwizards-all operation set has been removed The "Add school" module is no longer visible. This seems wrong to me: --- for flavor in users classes schools computers; do umc_operation_create "schoolwizards-$flavor" "School wizards - $flavor" "schoolwizards/$flavor" "schoolwizards/$flavor/*" "schoolwizards/classes" "schoolwizards/schools" done --- generated ACLs: --- (umc-acls -u Administrator show) Host: master Command: schoolwizards/classes Flavor: schoolwizards/classes Options: {} Host: master Command: schoolwizards/classes Flavor: schoolwizards/computers Options: {} Host: master Command: schoolwizards/classes Flavor: schoolwizards/users Options: {} Host: master Command: schoolwizards/classes/* Flavor: schoolwizards/classes Options: {} Host: master Command: schoolwizards/computers/* Flavor: schoolwizards/computers Options: {} Host: master Command: schoolwizards/schools Flavor: schoolwizards/classes Options: {} Host: master Command: schoolwizards/schools Flavor: schoolwizards/computers Options: {} Host: master Command: schoolwizards/schools Flavor: schoolwizards/users Options: {} Host: master Command: schoolwizards/users/* Flavor: schoolwizards/users Options: {}
(In reply to comment #9) > The "Add school" module is no longer visible. This seems wrong to me: This was a typo when assigning the operation set to the default operation set. ucs-school-umc-wizards (2.0.17-1) * fix typo; Bug #3048
OK - The schoolwizards-all operation set has been removed OK - For each flavor there is a operation set now OK - all schoolwizards umc operations sets are added to default-umc-all OK - changelog By default a school admin is not allowed to use any of the schoolwizards. But it is possible to give them the following umc rights schoolwizards-users schoolwizards-classes schoolwizards-schools schoolwizards-computers
UCS@school 3.1 R2 has been released: http://download.univention.de/doc/release-notes-ucsschool-3.1-rev2.pdf If this error occurs again, please use "Clone This Bug".