Instructors can set permissions that lock them out of a course

[dlglin]

On the permissions config page an instructor can set $permissionLevels{login}. If they set it to a permission higher than their own, then they will lock themself out of the course, and it will take shell access to fix.

This leads to a couple of broader questions:

1. If the default permission level for an action is higher than that of the current user, should the user be able to change it? For example on my server I have $permissionLevels{change_password} set to "nobody" since passwords are handled by LDAP, but I can't stop an instructor from changing this for their course.
2. Should a user be allowed to change a permission level to something higher than their own (as in this issue)?

[somiaj]

Unsure if there is a agreed upon approach to this, because it might change based on use case. But there is now a way to easily remove options from the configuration page for users who aren't admins, or all users using the new change_config_foo permission levels.

For instance if you are using LDAP and want to prevent users from changing the permission level to change passwords you could do something like $permissionLevels{'change_config_permissionLevels{change_password}'} = 'admin'; (or nobody) in localOverrides.conf or course.conf, and this would prevent professors from even seeing this configuration option, so this would address your first issue, it is possible to remove settings from the configuration page for non admin users that you don't want them to be able to change in the server configuration.

I'm not sure of a way to deal with part 2, also is nobody considered a higher permission level than professor, I would like my users to be able to set things to nobody, but do agree, maybe not allow professors to set things to admin (and maybe if it is already set to admin, not let them see or change it?).

[somiaj]

@dlglin Thanks for bringing this up, I just added the above to my local overrides so my users can't modify who can change passwords (since we use LTI + LDAP here too).