Managing ACF

From Alpine Linux
Revision as of 19:38, 5 August 2009 by Ttrask (talk | contribs) (Default users removed in alpine 1.9)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Managing Your ACF Installation

ACF is a powerful web application for configuring your alpine device. While all efforts are made to make ACF a secure application, it is, by its very nature, dangerous. The purpose of ACF is to give users the ability to administer the services running on the system. It is up to the system administrator to ensure that users do not receive more priviliges on ACF than they should have. Access control is provided by the following means:

  • System Configuration
  • User Management
  • Roles Management
  • Package-specific Management

System Configuration

System administrators can do much to limit inappropriate access to ACF by properly managing the firewall and http services on the alpine device. Lock down access to ACF as much as possible. The following steps are highly recommended:

  • Limit ACF to encrypted (HTTPS) access
  • Do not make ACF available on Internet connections (if possible)
  • Limit ACF access to specified IP or MAC addresses

User Management

ACF includes user management under the System | User Management menu. Select the New User button to create a new user. Separate user accounts should be created for each ACF user. Each user account may belong to any number of ACF roles.

In alpine 1.8, the system includes two default users: alpine and foo. The default password for both users is test123. Replace the default users as soon as possible. In alpine 1.9, you will be prompted to create an initial user the first time you try to log in.

Roles Management

ACF includes robust roles management under the System | Roles Management menu. Roles define the permissions that each user has in ACF. Specifically, they define which ACF actions a member of a role may invoke. The system provides built-in roles and the ability to create custom roles.

Built-in Roles

Each ACF package comes with built-in roles that define some typical usage scenarios. The five basic built-in roles are:

GUEST All users and guests (unauthenticated users) have access to basic status and login.
USER Typical end-users can view the status of services and restart them if necessary.
EDITOR Editors have the ability to change some settings using forms.
EXPERT Expert users can directly edit service configuration files.
ADMIN Administrators have access to all ACF actions.

ACF packages may also include built-in roles that define specific usage scenarios for that package. For instance, acf-openssl is a fully functionaly certificate authority that separates the roles of submiting and approving certificate requests:

CERT_REQUESTER Users may submit requests for certificates and download those certificates when approved.
CERT_APPROVER Users may approve certificate requests.

A system administrator may edit the built-in roles to add permissions, but may not delete the built-in roles or their default permissions. This feature may allow the system administrator to add some permission to one of the lower roles to meet his needs. This is the only way to modify the permissions of guests (unauthenticated users). More typically, a system administrator would assign each user to custom roles or to a combination of built-in and custom roles.

Custom Roles

Custom roles give the system administrator the ability to define roles that match the custom needs of his system. Custom roles may include as many or as few permissions as desired. So, a system administrator may fully define the permissions of each distinct user type in a separate role, or he may use combinations of more specific roles for each user.

Custom roles are created using the New Role button. The Create New Role and Edit Role forms list every ACF action currently installed on the system (depending on which ACF packages are installed). This list can be extensive if several ACF packages are installed. In general, each ACF package stands on its own, so permissions for one package do not depend on having permissions for any other packages. The built-in roles should be used as guides to show which permissions are typically grouped together.

Package-specific Management

ACF packages may include their own package-specific management.

acf-tinydns manages a tinydns DNS server and includes permissions management on a domain by domain basis. This is available under the Networking | DNS | Permissions tab. The tinydns ACF package is designed to keep configuration for each domain in a separate file (see the List Domains tab). Permissions can then be set as to which domains may be viewed / edited by a specific user or members of a particular role.