Managing ACF

Managing Your ACF Installation

ACF is a powerful web application for configuring your Alpine Linux 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 Linux 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

Tip: By default, ACF use mini_httpd and use port 443. If you would like to change this port you simply have to specify the port in /etc/mini_httpd/mini_httpd.conf and restart: rc-service mini_httpd restart

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 Linux 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 Linux 1.9 and later, you will be prompted to create an initial user the first time you try to log in. If you install ACF using the setup-acf script, you will be prompted for a password, and a root user will be created.

Warning: If you installed ACF before defining the root password, you must execute acfpasswd -s root

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.

These built-in roles can be selected on a controller-by-controller basis (ie. /alpine-baselayout/alpine-baselayout/ADMIN) or globally (ie. ADMIN). The global built-in roles consist of all of the permissions of all of the corresponding controller-by-controller roles (ie. ADMIN contains /x/y/ADMIN for every x and y installed).

ACF packages may also include built-in roles that define specific usage scenarios for that package. For instance, acf-openssl is a fully functional certificate authority that separates the roles of submitting 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.

More Information

For more information, please see Alpine Configuration Framework Design.