Description of problem: If the --log option is set to /dev/null when using the engine-backup command, /dev/null gets corrupt and needed to regenerate. Version-Release number of selected component (if applicable): 4.3.8 How reproducible: Always Steps to Reproduce: 1. Run engine-backup --mode=backup --scope=files --scope=db --scope=reportsdb --file=/tmp/output --log=/dev/null 2. SSH to the machine where you run the command 3. /dev/null is corrupt Actual results: $ ssh ovirtengine Last login: Mon Feb 10 09:25:10 2020 from XXX -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied Expected results: Log file set to /dev/null should be just dismissed. Additional info: /dev/null regeneration command: rm -f /dev/null; mknod -m 666 /dev/null c 1 3
Thanks for the report! Please note that --log is no longer mandatory, see bug 1530031. We do: touch "${LOG}" chmod 0600 "${LOG}" So the file is not really corrupted, and can be fixed by a mere 'chmod 666 /dev/null'. It's done (chmod 600) for security reasons. If we happen to leak there some password, I'd rather not have it exposed. I am not sure what the exact criteria should be, for not doing this. Just hard-code '/dev/null'? Not sure this is good enough, or even makes sense. Do you think we should also condition the chmod on $FILE? This is definitely more sensitive, as it definitely includes passwords (by design). In short, I can see your point, but am not sure a fix is really needed, considering the amount of potential future maintenance work this might require...
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.
Thanks for the fast answer! I understand your point and indeed hardcoding /dev/null is rather an ugly solution. If this is done for security reasons, probably the simplest way to handle the issue is just documenting it and warning against using /dev/null as the logfile? Otherwise I wouldn't waste much time with it either. $FILE should definitely be chmoded as well!
Frankly, I think your current bug report is enough as "documentation" - people that run into this flow and search the net, will now likely find it. I do not believe people will notice it by mere casual reading of docs, or care much, most of the time, so this will needlessly make also docs longer and harder to read.
Ok, AFAIC you can close the bug if you wish.
OK, closing. Thanks again for the report!