Bug 1713933

Summary: bacula-sd unable to access tape autoloader and drives. Unix group and SELinux changes required.
Product: [Fedora] Fedora Reporter: James Boyle <unixi>
Component: baculaAssignee: Simone Caronni <negativo17>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 30CC: andreas, jridky, negativo17, phracek, rvokal, vdolezal
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-05-26 15:36:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description James Boyle 2019-05-25 20:38:48 UTC
Description of problem:
Incorrect UNIX permissions and missing SELinux policy prevent the bacula storage director (bacula-sd) from being able to access the necessary tape drive and tape autochanger device files.

The components (including the principal component, bacula-storage) involved are:
bacula-client-9.4.2-1.fc30.x86_64
bacula-common-9.4.2-1.fc30.x86_64
bacula-console-9.4.2-1.fc30.x86_64
bacula-console-bat-9.4.2-1.fc30.x86_64
bacula-devel-9.4.2-1.fc30.x86_64
bacula-director-9.4.2-1.fc30.x86_64
bacula-docs-9.4.1-2.fc30.noarch
bacula-libs-9.4.2-1.fc30.x86_64
bacula-libs-sql-9.4.2-1.fc30.x86_64
bacula-storage-9.4.2-1.fc30.x86_64
kernel-5.0.16-300.fc30.x86_64
selinux-policy-3.14.3-37.fc30.noarch
selinux-policy-targeted-3.14.3-37.fc30.noarch

How reproducible:
Always

Steps to Reproduce:
1. Install and configure bacula-sd to use a tape library / autoloader.
2. Start the three bacula services (bacula-{fd,sd,dir}.
3. Attempt to write bacula labels to tape:
   - bconsole
     - label barcodes

Actual results:
# bconsole                                                                                
Connecting to Director localhost:9101                                                                    
1000 OK: 103 bacula-dir Version: 9.4.2 (04 February 2019)                                                 
Enter a period to cancel a command.                                                                      
**label storage=LTO5 pool=LTO5 slot=1-11 barcodes                                                         
Automatically selected Catalog: MyCatalog                                                                
Using Catalog "MyCatalog"                                                                                
Connecting to Storage daemon LTO5 at host.name:9103 ...                                             
Enter autochanger drive[0]: LTO5A                                                                        
Connecting to Storage daemon LTO5 at host.name:9103 ...                                             
3306 Issuing autochanger "slots" command.                                                                
Device "LTO5" has 0 slots.
No slots in changer to scan.


Expected results:
# bconsole
Connecting to Director localhost:9101
1000 OK: 103 bacula-dir Version: 9.4.2 (04 February 2019)
Enter a period to cancel a command.
*label storage=LTO5 pool=LTO5 slot=1-11 barcodes
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
Connecting to Storage daemon LTO5 at host.name:9103 ...
Enter autochanger drive[0]: Connecting to Storage daemon LTO5 at host.name:9103 ...
3306 Issuing autochanger "slots" command.
Device "LTO5" has 24 slots.
Connecting to Storage daemon LTO5 at host.name:9103 ...
3306 Issuing autochanger "list" command.
The following Volumes will be labeled:
Slot  Volume
==============
   1  T00001L5
   2  T00002L5
   3  T00003L5
   4  T00004L5
   5  T00005L5
   6  T00006L5
   7  T00007L5
   8  T00008L5
   9  T00009L5
  10  T00010L5
  11  T00011L5
Do you want to label these Volumes? (yes|no): yes
Connecting to Storage daemon LTO5 at host.name:9103 ...
Sending label command for Volume "T00001L5" Slot 1 ...
3304 Issuing autochanger "load Volume T00001L5, Slot 1, Drive 0" command.
3305 Autochanger "load Volume T00001L5, Slot 1, Drive 0", status is OK.
[SE0203] The Volume=T00001L5 on device="LTO5A" (/dev/nst0) appears to be unlabeled.
3000 OK label. VolBytes=64512 VolABytes=0 VolType=0 Volume="T00001L5" Device="LTO5A" (/dev/nst0)
Catalog record for Volume "T00001L5", Slot 1  successfully created.
[ ... truncated ... ]
3304 Issuing autochanger "load Volume T00011L5, Slot 11, Drive 0" command.
3305 Autochanger "load Volume T00011L5, Slot 11, Drive 0", status is OK.
[SE0203] The Volume=T00011L5 on device="LTO5A" (/dev/nst0) appears to be unlabeled.
3000 OK label. VolBytes=64512 VolABytes=0 VolType=0 Volume="T00011L5" Device="LTO5A" (/dev/nst0)
Catalog record for Volume "T00011L5", Slot 11  successfully created.
*

Additional info:
Installation should add the user 'bacula' to the 'tape' group in /etc/group:
tape:x:33:bacula

Installation should include the following SELinux policy:
module bacula-mtx 1.0;

require {
        type bacula_t;
        type scsi_generic_device_t;
        class chr_file { ioctl open read write };
}

#============= bacula_t ==============
allow bacula_t scsi_generic_device_t:chr_file { ioctl open read write };

Comment 1 Simone Caronni 2019-06-03 18:25:59 UTC
Thanks for reporting, same issue here but had no time yet to contribute to the upstream selinux-policy package where all the bacula policies are stored.

Comment 2 Simone Caronni 2019-06-03 19:50:30 UTC
RE(In reply to James Boyle from comment #0)
> Additional info:
> Installation should add the user 'bacula' to the 'tape' group in /etc/group:
> tape:x:33:bacula

This is not correct. The Storage Daemon starts with the group tape:

$ cat /etc/sysconfig/bacula-sd | grep SD
SD_USER=bacula
SD_GROUP=tape

And the various devices required for access are all accessible with group tape.

> Installation should include the following SELinux policy:
> module bacula-mtx 1.0;
> 
> require {
>         type bacula_t;
>         type scsi_generic_device_t;
>         class chr_file { ioctl open read write };
> }
> 
> #============= bacula_t ==============
> allow bacula_t scsi_generic_device_t:chr_file { ioctl open read write };

For this a pull request should be made here (look for bacula):

https://github.com/fedora-selinux/selinux-policy-contrib

Comment 3 James Boyle 2019-06-05 22:54:41 UTC
(In reply to Simone Caronni from comment #2)
> RE(In reply to James Boyle from comment #0)
> > Additional info:
> > Installation should add the user 'bacula' to the 'tape' group in /etc/group:
> > tape:x:33:bacula
> 
> This is not correct. The Storage Daemon starts with the group tape:
> 
> $ cat /etc/sysconfig/bacula-sd | grep SD
> SD_USER=bacula
> SD_GROUP=tape
> 
> And the various devices required for access are all accessible with group
> tape.

I forget exactly what failed until I made that change.  Maybe mtx wasn't executed with group "tape" set, maybe it was when I was adding the bacula labels, not sure...  I will remove the bacula from the group and test this week; I've got a sizeable backup job running at the moment.

> > Installation should include the following SELinux policy:
> > module bacula-mtx 1.0;
> > 
> > require {
> >         type bacula_t;
> >         type scsi_generic_device_t;
> >         class chr_file { ioctl open read write };
> > }
> > 
> > #============= bacula_t ==============
> > allow bacula_t scsi_generic_device_t:chr_file { ioctl open read write };
> 
> For this a pull request should be made here (look for bacula):
> 
> https://github.com/fedora-selinux/selinux-policy-contrib

Is the pull request something I should do?

Comment 4 Ben Cotton 2020-04-30 21:50:58 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 Ben Cotton 2020-05-26 15:36:00 UTC
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.