Bareos has a graphical tool for communicating with the Bareos Director. The WebUI is multilingual and provides detailed information about backup jobs, clients, FileSets, pools, volumes, and more. It’s also possible to start backup and restore jobs via the web interface. Our blog series gives an introduction to the Bareos WebUI. In this third episode: ACLs (Access Control Lists).
The first part of this series described the installation and configuration of the Bareos WebUI, and the second article gave an introduction to the dashboard and the modules. Both articles mentioned ACLs (Access Control Lists) briefly. So-called profiles control what users can see and do in the WebUI.
A quick reminder: the WebUI doesn’t have its own user management. Instead, for access to the graphical interface, you create accounts in the Bareos Director (a Console resource). When setting up a new Console resource, you also specify a Profile resource.
Tip: So far, we always talked about Bareos WebUI and Director on the same machine. It’s also possible to run the two services on different computers. In that case, you create Console and Profile resources on the Director. After that, run reload in the bconsole to load the new configuration.
This article takes a closer look at the configuration files in /etc/bareos/bareos-dir.d/profile and explains how to use ACLs in them. After that, we’re going to present a real-life example: an administrator gives two WebUI users access to different commands and backup jobs.
Profile Files: Structure and Syntax
The WebUI package installs three different profiles: webui-admin.conf (extensive permissions), webui-readonly.conf (read-only access), and webui-limited.conf.example (configuration template for restricted access). All files contain several ACL directives, for example, CommandACL (for commands), JobACL (access to jobs), ScheduleACL (access to schedules), etc.
Note: The parser, which reads the configuration files from top to bottom and from left to right, doesn’t care whether you use spaces in the directives’ names or not. In conclusion, you can write CommandACL or Command ACL. The parser removes all blanks during the import, anyway.
The directive’s name is followed by an equals sign and a list of comma-separated regular expressions. Depending on the ACL, the regex can be resource names, paths, or commands. A preceding exclamation mark prohibits a command, and the keyword *all* allows unrestricted access. The order is vital, so please make sure to negate first, then allow. For example, this means that *all* is always at the end of the list.
With this in mind, let’s take a look at the CommandACL directive and the commands used in this context. Some of them are mandatory, others aren’t. The Bareos documentation offers a list of all WebUI modules and their commands, showing which of them are required and which of them are optional.
Some commands in the included profiles start with a dot, such as .api, .clients, and .help. These so-called Dot Commands are internal API commands, used in scripts or Bareos interfaces, like the WebUI or bconsole. For this article and consequently for defining WebUI access, they don’t matter—then again, please make sure not to negate or exclude the Dot Commands. Otherwise, the WebUI may no longer work correctly.
Real-life Example
Let’s look at a practical case: Alice and Bob work at the same company, in two different departments, A and B. The IT department has decided that Alice and Bob should be able to assist their own departments when it comes to backup and restore. They need access to the Bareos WebUI and permission to restore their department’s backups, but not the other department’s backups. Apart from that, Alice and Bob should be allowed to run backups and to rerun failed jobs. Finally, they need to be able to cancel running backup jobs of the respective department.
The administrator creates the following two Console resources for the employees:
Console {
Name = "alice"
Password = "secret"
Profile = "webui-user-department-a"
TlsEnable = false
}
Console {
Name = "bob"
Password = "secret"
Profile = "webui-user-department-b"
TlsEnable = false
}In the profile configuration files, the administrator makes sure that each department has its own location for the backups (file-department-a and file-department-b). Pools for full, differential, and incremental backups are also defined. Each department, A and B, has 3 clients to back up. Lastly, for each of those file daemons there is a backup job and an associated fileset.
This is what the profile file for department A looks like:
Profile {
Name = "webui-user-department-a"
CommandACL = .api, .help, use, version, status, show
CommandACL = list, llist
CommandACL = run, rerun, cancel, restore
CommandACL = .clients, .jobs, .filesets, .pools, .storages, .defaults, .schedule
CommandACL = .bvfs_update, .bvfs_get_jobids, .bvfs_lsdirs, .bvfs_lsfiles
CommandACL = .bvfs_versions, .bvfs_restore, .bvfs_cleanup
JobACL = backup-department-a-host-1, backup-department-a-host-2, backup-department-a-host-3, RestoreFiles
ScheduleACL = WeeklyCycle
CatalogACL = MyCatalog
PoolACL = department-a-full, department-a-diff, department-a-inc
StorageACL = file-department-a
ClientACL = department-a-host-1, department-a-host-2, department-a-host-3
FilesetACL = fileset-department-a-host-1, fileset-department-a-host-2, fileset-department-a-host-3
WhereACL = *all*
}The profile for department B looks similar:
Profile {
Name = "webui-user-department-b"
CommandACL = .api, .help, use, version, status, show
CommandACL = list, llist
CommandACL = run, rerun, cancel, restore
CommandACL = .clients, .jobs, .filesets, .pools, .storages, .defaults, .schedule
CommandACL = .bvfs_update, .bvfs_get_jobids, .bvfs_lsdirs, .bvfs_lsfiles
CommandACL = .bvfs_versions, .bvfs_restore, .bvfs_cleanup
JobACL = backup-department-b-host-1, backup-department-b-host-2, backup-department-b-host-3, RestoreFiles
ScheduleACL = WeeklyCycle
CatalogACL = MyCatalog
PoolACL = department-b-full, department-b-diff, department-b-inc
StorageACL = file-department-b
ClientACL = department-b-host-1, department-b-host-2, department-b-host-3
FilesetACL = fileset-department-b-host-1, fileset-department-b-host-2, fileset-department-b-host-3
WhereACL = *all*
}Bareos and PAM Integration
As you can see, it’s not too complicated to define ACLs in Bareos and decide what a user can see and execute in the Bareos WebUI. Especially for larger companies, this is a good way to set up multiple administrative user accounts with different permissions. This way, employees from different departments can access their own backups and jobs via the graphical interface.
On top of its own authentication, Bareos can use PAM (Pluggable Authentication Modules). This way, an administrator can set up a larger number of WebUI accounts without having to maintain their own passwords for Bareos. Our manual explains the basic setup. Moreover, a GitHub article describes how to configure Bareos so that users are automatically created in the Bareos Director when they first log in to the WebUI. As a result, no manual adjustments are necessary for new users in the Bareos system.
Note: When using PAM, only a single Console resource is required. The accounts are maintained via User resources. These are “stripped down” Console resources which contain ACL settings, but no entries for the password or TLS.