Skip to content

Knowledgebase

Restricting a Webmin administrator to required modules

control-panels, servers

Grant a Webmin administrator only the modules and actions their job requires. A module can expose powerful system operations even when the main interface looks limited, so test both module access and its internal access-control settings.

What you need before you begin

Use an existing authorized full administrator and retain that working session. Write down the exact delegated tasks, allowed users, paths and services. Keep Webmin updated before relying on access controls and avoid using a shared root login for delegated work.

01 Restrict a Webmin administrator to required modules

  1. Open Webmin > Webmin Users and create a distinct user or appropriate group. Set its authentication method and choose only the required modules.
  2. Open the access-control settings for each assigned module. Restrict allowed filesystem paths, Unix users, service units or editable objects where the module supports those controls.
  3. For a user-management delegate, prevent editing privileged accounts, granting extra modules, changing module ACLs or moving users into powerful groups unless explicitly required.
  4. Consider indirect escalation. A user who can edit a root-run script, arbitrary scheduled commands or unrestricted service definitions may effectively have root access even without the Terminal module.
  5. Save and log in through a separate browser session as the limited user. Test permitted work and representative forbidden actions without closing your full administrator session.
  6. Record the approved permissions and periodically review group inheritance, new modules and role changes.

Is hiding a menu enough to restrict access?

No. Use Webmin module assignment and module-specific ACLs. Visual customization does not establish a reliable authorization boundary for direct URLs or API calls.

Confirm the expected result

Confirm the user sees only the intended modules and that direct access to disallowed actions is rejected. Verify restrictions inside each module rather than relying on hidden navigation. Check the actions log after a controlled test to support accountability.

Troubleshoot unexpected results

If a required task is blocked, identify the narrow missing permission instead of granting every module. If a dangerous capability was exposed, remove it, terminate inappropriate sessions and review recent actions. Do not edit the only administrator account into a role that cannot restore permissions.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support