Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1801104

Summary:	--log=/dev/null on engine-backup corrupts /dev/null
Product:	[oVirt] ovirt-engine	Reporter:	nicolas
Component:	Backup-Restore.Engine	Assignee:	Yedidyah Bar David <didi>
Status:	CLOSED WONTFIX	QA Contact:	Lucie Leistnerova <lleistne>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	4.3.8.2	CC:	bugs
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-02-11 07:19:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Integration	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description nicolas 2020-02-10 09:35:15 UTC

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

Comment 1 Yedidyah Bar David 2020-02-10 10:15:49 UTC

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...

Comment 2 RHEL Program Management 2020-02-10 10:15:55 UTC

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.

Comment 3 nicolas 2020-02-10 11:10:04 UTC

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!

Comment 4 Yedidyah Bar David 2020-02-10 12:52:04 UTC

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.

Comment 5 nicolas 2020-02-10 13:51:39 UTC

Ok, AFAIC you can close the bug if you wish.

Comment 6 Yedidyah Bar David 2020-02-11 07:19:49 UTC

OK, closing. Thanks again for the report!