Ignoring World Writeable my.cnf Error

[jimbo8098]

When running holland bk I currently note that it creates a world-writeable file within the backup directory. I'm not entirely sure why!

Environment

I am using a docker container running CentOS 7.7 with a Chef Kitchen environment. The environment effectively spins up a new Cent 7.7 box every time with our configuration. This includes holland which is installed using a holland cookbook, specifically this one:

https://github.com/djoos-cookbooks/hollandbackup

I realise this is very old and I'm currently making a PR to bring them up to date which is why I'd like to understand what exactly is wrong with the config here.

For those unfamiliar, Chef cookbooks take a bunch of parameters and build configs based on them in an effort to quickly create mirrored or similar configs.

Current Situation

With the configuration we have, we specify a backupset which has a host, user, pass, single database and a plugin (mysqldump). When I run holland -d bk <backupset> I see the following output:

[root@dbvault ~]# holland -d bk <backupset>
Adding plugin directory: ''
Holland 1.1.21 started with pid 28136
--- Starting backup run ---
Set advisory lock on /etc/holland/backupsets/<backupset>.conf
Creating backup path /backups/<backupset>/20200217_180322
Writing out config to /backups/<backupset>/20200217_180322/backup.conf
 [before-backup-command]> sudo systemctl restart ssh-tunnel-manager && sleep 10
Estimating size of mysqldump backup
Estimated Backup Size: 3.56GB
Missing backup.conf from last backup
Starting backup[<backupset>/20200217_180322] via plugin mysqldump
Using mysqldump executable: /usr/bin/mysqldump
Executing: /usr/bin/mysqldump --no-defaults --version
mysqldump version 10.0.38
Using mysqldump option --flush-privileges
Using mysqldump option --routines
Using mysqldump option --events
Using mysqldump option --max-allowed-packet=128M
Using gzip compression level 1 with args
Wrote backup manifest /backups/<backupset>/20200217_180322/backup_data/MANIFEST.txt
* Executing: /bin/gzip -1
Executing: /usr/bin/mysqldump --defaults-file=/backups/<backupset>/20200217_180322/my.cnf --flush-privileges --routines --events --max-allowed-packet=128M --single-transaction <database>
/usr/bin/mysqldump[28281]: Warning: World-writable config file '/backups/<backupset>/20200217_180322/my.cnf' is ignored
/usr/bin/mysqldump[28281]: mysqldump: Got error: 1049: "Unknown database '<database>'" when selecting the database
mysqldump exited with non-zero status 2
Backup failed after 13.15 seconds
sys.exc_info(): (<class 'holland.core.backup.base.BackupError'>, BackupError('mysqldump exited with non-zero status 2',), <traceback object at 0x7fcb49ee92d8>)
Purged failed backup: <backupset>/20200217_180322, failed-backup
Backup failed: Failed backup: <backupset>
Released lock /etc/holland/backupsets/<backupset>.conf
--- Ending backup run ---

When I check the backup directory, for the my.cnf file, I can't see the datestamped directory suggesting that since it failed, it was removed. I did manage to stop the backup at just the right moment and was able to see the structure alongside the my.cnf file and found that the file was listed with, rather oddly, 022 permissions, writeable to all except the owner! The owner, since it's root, is able to write to that file anyway but it's odd.

Expectation

I would have thought that the file would be created with the default chmod values for that directory but it would appear not. Acceptable file permissions would be 644 in this case I reckon but I don't see this being set in the source code anywhere although I must confess, Python is not a language I'm majorly familiar with (shocking I know).

[soulen3]

Hello jimbo8098,

Thanks for taking the time to report this issue. I'm currently unable to reproduce it. I'm using the following docker container for testing.

https://hub.docker.com/layers/soulen3/holland/centos7_mariadb_5.5/images/sha256-05fd23c59f6d7a1f30f5cbfc961bc31f3aa883c79405a16c7d469b025f3f2473?context=repo

Holland lets you set the umask in the holland.conf file. It defaults to 0007. On my test machine, holland wrote out the file with the expected permissions.

[root@2d89d17f5e08 /]# ls -l /var/spool/holland/mysqldump/20200220_171007/my.cnf
-rw-rw----. 1 root root 9 Feb 20 17:10 /var/spool/holland/mysqldump/20200220_171007/my.cnf

Can you please check the umask setting in /etc/holland/holland.conf?

Also note that you can configure holland to keep the backup contents for a failed backup run. Change auto-purge-failures to false in the backupset configuration file, and holland won't purge failed runs until there's a good backup is completed.

[jimbo8098]

Ah, thank you! Setting the umask in /etc/holland/holland.cnf to 0007 fixed the issue.