4.14. Module Access Control
It is possible to grant a Webmin user or group access to only a subset of features in the Users and Groups module. This is most commonly used to allow a subadministrator the right to edit only selected users and groups on the system, and to change their attributes in only limited ways. In a virtual hosting environment, for example, you may want to give a Webmin user the ability to create and edit up to 10 users with UIDs in a limited range, and home directories under a fixed directory. These privileges give the user no way to gain root access and affect users that do not belong to him.
Chapter 52 explains how to create additional Webmin users and edit their module access control in more detail. The following steps cover just the parts of the process that grant the kind of limited access that is specific to the Users and Groups module:
1. | In the Webmin Users module, click on Users and Groups next to the name of the user that you want to edit. This will take you to the access control form shown in Figure 52.3. |
2. | Change the Can edit module configuration? field to No. |
3. | The UNIX users who can be edited field controls the users that can be changed by this Webmin user. You would typically set it to Users with UIDs in range and enter maximum and minimum UIDs into the fields next to it, such as 5000 and 5010. |
4. | To allow the addition of new UNIX users, set the Can create new users? field to Yes. |
5. | Set the Can view batch file form? option to No. This will prevent the Webmin user from creating and editing users from a batch script, which is not normally necessary. Allowing it, however, does not grant the user any additional privileges and is not a security risk. |
6. | For the UIDs for new and modified users fields, enter the same UIDs as in Step 4. |
7. | Deselect the More than one user can have the same UID option, but leave the UIDs of existing users can be changed option selected. An untrusted subadministrator should not normally be allowed to create multiple users with the same UID due to the problems that this can cause. When UID clashes are prevented, the Webmin user will not be able to create any more UNIX users than fit in his allowed UID range. |
8. | In the Allowed groups for new or modified users field, you would typically select the Only groups option and enter the names of any groups of which new users can be primary or secondary members. Normally you would just enter a single group like users. Leaving this field set to All groups is a very bad idea, because it would allow the creation of users who are members of the root or bin groups, and who can thus edit important system files and executables. The Groups with GIDs in range option can be useful if this Webmin user is allowed to create multiple groups of his own within the same GID range. |
9. | To restrict the shells that a new user can be assigned, set the Allowed shells for new or modifed users to Listed and enter their paths into the text box below. This can be useful to allow the creation of only mail-only users who always have the shell /bin/false. |
10. | Set the Home directories must be under field to a directory that will only be used for accounts created by this Webmin user. Setting it to /home is a bad idea, because this would allow the subadministrator to rename or delete directories belonging to other users that are under /home. Instead, enter something like /home/subadmin. To force every user's home directory to be based on his username (such as /home/subadmin/username), check the Home directory is always same as username box. |
11. | To stop the Webmin user from deselecting some of the options at the bottom of the user creation, editing and deletion forms, deselect the matching Allowed on save options. Any that are not chosen will effectively always be turned on. |
12. | Assuming you just want the Webmin user to create and edit UNIX users, set the UNIX groups who can be edited field to No groups. |
13. | If you want to restrict the user from viewing recent logins, change the Can display logins by field. Any user who can login with telnet or SSH can run the last command anyway to display logins, so setting this option to No users does not usually make your system any more secure. |
14. | Finally, click Save. You will be returned to the module's main page and the new access control restrictions will be immediately applied to the Webmin user. |
Be careful when granting a Webmin user access to certain UNIX users, as a mistake may allow him to edit the root user or create a new user who is equivalent to root. There are also many other users like bin, uucp, and httpd that own important system files or are used for running server and daemon processes. Someone who can edit or login as one of these users could gain root privileges on your system or access files that he is not supposed to.
Often the access control in the Disk Quotas and Scheduled Cron Jobs module is set up to allow editing of the quotas and Cron jobs of the same UNIX users as those that can be edited and created in this module. All modules support the UID range and primary group access control options, which can be set in the same way.
It is also possible to use the Users and Groups access control form to allow a user to edit or create selected UNIX groups, though this is not generally as useful. Granting an untrusted user the rights to edit all groups on the system is a bad idea, as he would make himself a member of the root or bin group and so be able to read or write critical files.