Forgot to mention that this bug is present in F8, F9, devel and EPEL 5.

Removing groups to make bug publicly accessible.  There is no need to keep it
private.

Felix, what is your expected fix for this?  Upstream treats this as
documentation issue and it as treated as such.  Do you propose to diverge from
upstream and use modified scripts using environment or my.cnf file by default?

Felix, could you please reply to the previous question? If you don't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. 

Andreas or Tomas -- Either of you have any other ideas on this or should it be closed?

Sorry about my inactivity here. The only real solution would be (imho) to use neither command line arguments nor environment variables. So I guess the solution would be to add config files like my.cfg for MySQL to /etc/bacula where the password should be stored and remove the usage of command line parameters from the catalog backup scripts.

Disadvantage: The user has to enter his password twice (bacula-dir.conf, my.cnf).

If there is a solution we agree on, I can build a patch for the bacula rpm.

Hello,

I'm doing some housekeeping in Bacula bugs, any news regarding this or it can be closed with INSUFFICIENT_DATA as in comment #3?

Thanks,
--Simone

AFAICS, make_catalog_backup in bacula-director-5.2.10-4.fc18 still calls mysqldump with password as command line argument.  It is also passed to the script as command line argument, with the following warning in the script:

#  $3 is the password with which to access the database or "" if no password
#     (default ""). WARNING!!! Passing the password via the command line is.
#     insecure and should not be used since any user can display the command.
#     line arguments and the environment using ps.  Please consult your
#     MySQL or PostgreSQL manual for secure methods of specifying the
#     password.

1) Fedora 17 (5.2.0+):

I will remove it. It is not referenced by anything in Bacula and as stated in the manual is just an example.

In the same directory exists a newer "make_catalog_backup.pl" which reads the same password bacula-dir uses from the config file and is the one used by the catalog backup job to backup the database.

2) Fedora 16 (5.0.3):

Only make_catalog_backup.pl is available.

3) Epel 5 (2.4.4)

There is no perl variant, only the script one is available and is referenced in the default job.

I can put the same perl script in the Epel 5 package with a symlink, but the job needs to be changed like it is in 5.0.3; so from:

  # This creates an ASCII copy of the catalog
  # WARNING!!! Passing the password via the command line is insecure.
  # see comments in make_catalog_backup for details.
  # Arguments to make_catalog_backup are:
  #  make_catalog_backup <database-name> <user-name> <password> <host>
  RunBeforeJob = "@scriptdir@/make_catalog_backup @db_name@ @db_user@"

to 

  # This creates an ASCII copy of the catalog
  # Arguments to make_catalog_backup.pl are:
  #  make_catalog_backup.pl <catalog-name>
  RunBeforeJob = "/usr/libexec/bacula/make_catalog_backup.pl MyCatalog"
  # This deletes the copy of the catalog

Removed the script in f17 packages.

Sorry for the delay, I was pretty busy.

I created a build for RHEL 5 with the perl variant included:

http://koji.fedoraproject.org/koji/buildinfo?buildID=344922

The default config file and everything point at it, so for new installations this is not a problem. Any idea on how to make the change in the director config file for the user?

From:

RunBeforeJob = "/usr/libexec/bacula/make_catalog_backup database user (and maybe host and port)"

To:

RunBeforeJob = "/usr/libexec/bacula/make_catalog_backup.pl MyCatalog"

Where the "MyCatalog" tag is taken from the relevant stanza in the director's config file.

Is it ok to execute in the %post section of the package a sed command on the user's configuration file?

Thanks,
--Simone

bacula-5.2.10-5.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/bacula-5.2.10-5.fc17

(In reply to comment #9)
> Is it ok to execute in the %post section of the package a sed command on the
> user's configuration file?

Such edits are usually considered something that should be avoided.  If it's config file, and the default configuration in rpm was changed, users with the default config should get it and those with modified should have it as .rpmnew.

Thanks, and how are the users notified of the change?

When rpm creates a .rpmnew or .rpmsave during the package installation, it prints a message about it.

Ok then, if the normal rpm logic is enough I'm ready. bacula-2.4.4-7.el5 is pending stable, as soon as it enters it I'm gonna push bacula-2.4.4-10.el5 which fixes this and other bugs.

Regards,
--Simone

bacula-2.4.4-10.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/bacula-2.4.4-10.el5

Package bacula-2.4.4-10.el5:
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing bacula-2.4.4-10.el5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-6674/bacula-2.4.4-10.el5
then log in and leave karma (feedback).

bacula-5.2.10-5.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

bacula-2.4.4-10.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Simone, the "fix" that you included into Bacula in EPEL 5 simply breaks
everything related to /usr/libexec/bacula/make_catalog_backup.pl: That
script calls "dbcheck -B".

First mistake is, that this is a copy of bscan.variant and not of the more
correct dbcheck.variant. Second mistake is that "dbcheck -B" is absolutely
not supported in such an old version of Bacula. I tried to backport that,
but it seems that it is not that trivial because the changed code also has
a dependency on other Bacula code parts that have been rewritten in parts.

Why the heck did you not proper test this before breaking things that way
and even incompatible? I expect packagers to do a good job including tests
of their work - this is EPEL, not Fedora!

Okay...I think, I managed to write a proper patch. However, I still expect
somebody modifying a package to test the changes at least once - which did
not happen here obviously (make_catalog_backup.pl even failed a Perl syntax
check). The "dbcheck -B" works here, make_catalog_backup.pl backups as it's
expected and dbcheck/bscan/bcopy base on the proper database variant while
dbcheck is really dbcheck and not bscan anymore.

bacula-2.4.4-12.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/bacula-2.4.4-12.el5

bacula-2.4.4-12.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

The affected script is still shipped as part of Red Hat Enterprise Linux 6. However, it is not used by default and there are security warnings within the script itself and the relevant documentation:

http://www.bacula.org/en/dev-manual/main/main/Catalog_Maintenance.html#SECTION0042140000000000000000

or /usr/share/doc/bacula-docs-5.0.0/main.pdf chapter 42 section 14.

The default configuration uses make_catalog_backup.pl script, which is not affected by this issue.

Statement:

The Red Hat Security Response Team has rated this issue as having low security impact. This issue is not currently planned to be addressed in Red Hat Enterprise Linux 6. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.