When a backup of a catalog occurs and the script runs as bacula (using the bacula group), it will fail for permissions when executing /usr/sbin/dbcheck. If the group permissions of dbcheck are set from root to bacula, this resolves this issue (as the file permissions are already 750). The ebuild patch I am including should set this during install. :) Reproducible: Always
Created attachment 307639 [details, diff] ebuild patch
(In reply to comment #0) > When a backup of a catalog occurs and the script runs as bacula (using the > bacula group), it will fail for permissions when executing > /usr/sbin/dbcheck. If the group permissions of dbcheck are set from root to > bacula, this resolves this issue (as the file permissions are already 750). > I am not quite sure what you are talking about. Which script you refer to? How and when do you run dbcheck?
During a backup of a catalog job, the "RunBeforeJob" script (which actually does the work) is set to use "/usr/libexec/bacula/make_catalog_backup.pl DefaultCatalog". Within the Perl at line 45 is: my $dir_conf='/usr/sbin/dbcheck -B -c /etc/bacula/bacula-dir.conf'; which is then executed at line 128. As the script is run as the bacula user (with bacula group) the script will fail with a: 02-Apr 05:41 foobar-dir JobId 1002: shell command: run BeforeJob "/usr/libexec/bacula/make_catalog_backup.pl DefaultCatalog" 02-Apr 05:41 foobar-dir JobId 1002: BeforeJob: sh: /usr/sbin/dbcheck: Permission denied 02-Apr 05:41 foobar-dir JobId 1002: BeforeJob: Can't find your catalog (DefaultCatalog) in director configuration 02-Apr 05:41 foobar-dir JobId 1002: Error: Runscript: BeforeJob returned non-zero status=1. ERR=Child exited with code 1 This is due to the "dbcheck" executable (along with all of the other executables) having their default ownership/permissions set to root:root/750 (respectively). If one instead set the group ownership of "dbcheck" to the "bacula" group (along with the bacula-dir.conf file with root:bacula/640) the script can execute this successfully (the other executables do not need this modification). The ebuild patch I included sets this during the install phase, alleviating the issue. The "libexec" directory already has set these permissions in the ebuild at line 331.
Can I help (I assume this makes sense, albeit the patch is a rough cut)?
(In reply to comment #4) > Can I help (I assume this makes sense, albeit the patch is a rough cut)? Not at the moment. But thanks anyway. Wrt your previous post, I see your point now. I am wondering why I do not have the same problem as I use the make_catalogue_backup.pl script myself (and on more than one system). I have to find out what is going on before a change to the ebuild makes sense. One question which my be related to the problem is the set of USE flags at your side and specially the database in use. Can you please provide that information?
mysql (it's a bit heavy weight, but the recovery tools are excellent). Consequently USE="mysql readline ssl tcpd vim-syntax -X -bacula-clientonly -bacula-nodir -bacula-nosd -ipv6 -logwatch -postgres -python -qt4 -sqlite3 -static" I believe a while ago the daemon was run as root (not the bacula user), which would ameliorate the issue. I tend to run things a little more cautiously (if at all possible), hence the limitation of what that user is allowed.
(In reply to comment #6) > mysql (it's a bit heavy weight, but the recovery tools are excellent). > Consequently USE="mysql readline ssl tcpd vim-syntax -X -bacula-clientonly > -bacula-nodir -bacula-nosd -ipv6 -logwatch -postgres -python -qt4 -sqlite3 > -static" > > I believe a while ago the daemon was run as root (not the bacula user), > which would ameliorate the issue. I tend to run things a little more > cautiously (if at all possible), hence the limitation of what that user is > allowed. Hmm. Same configuration here. Same error if I try to run the script from the shell. But no error if it is run from inside bacula. Catalog backup works like a charme. I have to dig a little bit deeper...
Paul, please check as what user and group your director is running. A simple 'ps ax|grep bacula' should do. By default bacula director runs as root:bacula which can run the make_catalog_backup.pl as well as the dbcheck file without errors.
It's running as bacula:bacula (perhaps comment 6 wasn't stated as clearly as I should have). All of the daemons are run as the bacula user due to my perhaps overly cautious approach to security. For the most part this is fine, as access to the database is controlled (as are where else the daemon can go). All in all, this has not been an issue except when updating the software wherein the default permissions to db_check are set to only allow root access (and not the bacula program) even though the script files have the requisite permissions. Obviously the bacula user would not need to change the program (only execute it), hence my suggested modification would allow for the bacula group (of which the bacula user is the only member) and retain root permissions for write. Honestly, it's not that big an issue to skip this patch (it would just save me the time and remembering to do it every time). I expected that it I was having an issue, then others might as well hence the submission.
(In reply to comment #9) > It's running as bacula:bacula (perhaps comment 6 wasn't stated as clearly as > I should have). All of the daemons are run as the bacula user due to my > perhaps overly cautious approach to security. For the most part this is > fine, as access to the database is controlled (as are where else the daemon > can go). > The comment was clear, but I did not read it right. My fault. As I see it now, your proposed changes makes sense only for your use case, which deviates from the normal installation. but are not needed for the normal installation. I do not think that we will change the ebuild in that direction as long as we run bacula director as root:bacula. I would suggest to simple make an adapted ebuild under /usr/local/portage with your modifications.
