52.1. Introduction to Webmin Users, Groups, and Permissions
A standard, out-of-the-box Webmin installation has only one user (called root or admin) who can use every feature of every module. On a home or office system used by just one person, that is all you need. Even if your system has multiple users, there may be only one who needs to perform system administration tasks.
There are, however, many situations in which the administrator may want to give some people access to a subset of Webmin's features. For example, you may have a person in your organization whose job it is to create and edit DNS zones and records. On a normal UNIX system, this person would have to be given root access so that he can edit the zone files and restart the DNS server when necessary. Unfortunately, once someone is able to log in as root, he has full control of the system and can do whatever he wants.
Webmin solves this kind of problem by allowing you to create additional users who can log in, but only access a few modules. You can further restrict what the user can do within each module so he cannot abuse its features to perform actions that he is not supposed to. Because Webmin still runs with full root privileges even when used by a restricted user, it still has access to all the configuration files and commands that it needs.
Some examples of the kind of access control restrictions that you can set up are:
Creating a user with the right to edit directives in only a few Apache virtual servers that he owns. Global settings or directives in other virtual hosts cannot be edited.
Allowing a user access to only one MySQL database, but not to other databases or user permissions. Similar access control can be set up for PostgreSQL.
Giving a user the right to edit and create UNIX users with UIDs within a certain range and with home directories under a restricted directory. Important system users such as root or bin cannot be edited or even viewed.
Giving a user access to the Squid access control list, but not to other functions. The user could be allowed to apply his configuration changes, but not to start or stop the proxy server.
Creating custom commands and then giving a user the rights to run only some of them, but not create or edit any.
Allowing a user to view and cancel print jobs in the Printer Administration module, but not edit or create actual printers.
Many of these rights would be impossible to grant using command-line tools without giving root access to the entire system. Even programs like sudo are limited when it comes to allowing a user to edit only part of a file, or run a command with only certain arguments.
You must be very careful when granting access to untrusted Webmin users, however, as even a small mistake in the access control configuration may allow the user to edit arbitrary files on your system or run commands as root. All it takes is a small hole for an attacker to sneak through and take total control of your system. Webmin's access control capabilities give you the power to lock down users, but only if used properly.
Even though it is possible to create a user with access to only his own email, home directory, and password, Webmin is not always the best way to provide this kind of single-user web interface. A superior program is Usermin, which was developed by the same author and shares much of the Webmin code and user interface. It is designed to give each UNIX user access to only those things that he would be able to access at the command line, such as his email, home directory files, and GnuPG configuration. Usermin runs most of its code with the permissions of the logged-in user, so there is far less chance of a user doing things that he is not supposed to, or even gaining root access. See Chapter 47 “Usermin Configuration” for more details on how you can manage Usermin from within Webmin.