Red Hat Bugzilla – Bug 984503
Incorrect permissions against /tmp can result in looping OvfWriter failures
Last modified: 2015-09-22 09:09 EDT
Description of problem:
Incorrect permissions against /tmp can result in looping OvfWriter failures as we attempt to end the task (BZ#984491) :
2013-07-06 21:06:15,423 ERROR [org.ovirt.engine.core.bll.EntityAsyncTask] (pool-3-thread-49) EntityAsyncTask::EndCommandAction [within thread]: EndAction for action type ImportVm threw an exception: org.ovirt.engine.core.compat.CompatException: java.io.IOException: Permission denied
at org.ovirt.engine.core.compat.backendcompat.Path.GetTempFileName(Path.java:23) [engine-compat.jar:]
at org.ovirt.engine.core.utils.ovf.OvfWriter.<init>(OvfWriter.java:34) [engine-utils.jar:]
at org.ovirt.engine.core.utils.ovf.OvfVmWriter.<init>(OvfVmWriter.java:27) [engine-utils.jar:]
at org.ovirt.engine.core.utils.ovf.OvfManager.ExportVm(OvfManager.java:22) [engine-utils.jar:]
at org.ovirt.engine.core.bll.VmCommand.UpdateVmInSpm(VmCommand.java:182) [engine-bll.jar:]
at org.ovirt.engine.core.bll.VmCommand.UpdateVmInSpm(VmCommand.java:156) [engine-bll.jar:]
at org.ovirt.engine.core.bll.ImportVmCommand.UpdateVmImSpm(ImportVmCommand.java:984) [engine-bll.jar:]
at org.ovirt.engine.core.bll.ImportVmCommand.endVmRelatedOps(ImportVmCommand.java:974) [engine-bll.jar:]
at org.ovirt.engine.core.bll.ImportVmCommand.EndImportCommand(ImportVmCommand.java:965) [engine-bll.jar:]
at org.ovirt.engine.core.bll.ImportVmCommand.endSuccessfully(ImportVmCommand.java:924) [engine-bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.internalEndSuccessfully(CommandBase.java:512) [engine-bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.endActionInTransactionScope(CommandBase.java:459) [engine-bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1374) [engine-bll.jar:]
at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTransaction(TransactionSupport.java:204) [engine-utils.jar:]
at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInRequired(TransactionSupport.java:142) [engine-utils.jar:]
at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:109) [engine-utils.jar:]
at org.ovirt.engine.core.bll.CommandBase.endAction(CommandBase.java:405) [engine-bll.jar:]
at org.ovirt.engine.core.bll.Backend.endAction(Backend.java:369) [engine-bll.jar:]
While the exception is valid should we try to use another location if /tmp is not accessible like this?
Version-Release number of selected component (if applicable):
rhevm-3.1.0-50.el6ev.noarch Sun 24 Mar 2013 08:42:37 PM GMT
rhevm-backend-3.1.0-50.el6ev.noarch Sun 24 Mar 2013 08:42:30 PM GMT
Steps to Reproduce:
1. Break /tmp permissions with chmod 1770 etc.
2. Try to import/export, edit the guest in some way that will result in OVF modification etc.
3. Task will loop attempting to end successfully.
OvfWriter fails due to /tmp permission issues.
OvfWriter attempts to use another scratch space before failing.
Lee, why do you think it is valid for /tmp to have non standard permissions? Do you think that ovirt-engine is the only application that will break in this mode?
Based on POSIX:
The following directory shall exist on conforming systems and shall
be used as described:
A directory made available for applications that need a place to
create temporary files. Applications shall be allowed to create
files in this directory, but shall not assume that such files
are preserved between invocations of the application.
But let's say /tmp is not writable... why do you think that any other place application will assume that is writable will be writable and not modified by sysadmin?
Anyway, as a solution you can add -Djava.io.tmpdir=<whatever> to redirect jvm temp directory, example:
(In reply to Alon Bar-Lev from comment #1)
> Lee, why do you think it is valid for /tmp to have non standard permissions?
> Do you think that ovirt-engine is the only application that will break in
> this mode?
I don't think it is valid for /tmp to have non standard permissions and obviously other applications may suffer if they have been changed.
However at present this results in a non intuitive task failure error in the UI and in some cases a looping task that continuously fails (BZ#984491).
If you feel that attempting to switch to a location already used by engine (ie. /var/tmp/ovirt-engine) isn't valid then we should at least improve the exception being thrown and the error displayed in the UI.
(In reply to Lee Yarwood from comment #2)
> If you feel that attempting to switch to a location already used by engine
> (ie. /var/tmp/ovirt-engine) isn't valid then we should at least improve the
> exception being thrown and the error displayed in the UI.
I think I can make the process do all sort of strange behaviors regadless the safeguards.
But I agree that command should fail and not loop.
fixing the loop should be enough, see bug 984491
*** This bug has been marked as a duplicate of bug 984491 ***