Bug 984503

Summary: Incorrect permissions against /tmp can result in looping OvfWriter failures
Product: Red Hat Enterprise Virtualization Manager Reporter: Lee Yarwood <lyarwood>
Component: ovirt-engineAssignee: Michal Skrivanek <michal.skrivanek>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.2.0CC: acathrow, alonbl, audgiri, iheim, lpeer, Rhev-m-bugs, yeylon
Target Milestone: ---Keywords: Triaged
Target Release: 3.3.0   
Hardware: All   
OS: Linux   
Whiteboard: virt
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-29 13:09:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Lee Yarwood 2013-07-15 11:55:18 UTC
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

How reproducible:
Always

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.

Actual results:
OvfWriter fails due to /tmp permission issues.

Expected results:
OvfWriter attempts to use another scratch space before failing.

Additional info:

Comment 1 Alon Bar-Lev 2013-07-15 17:50:41 UTC
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[1]:
---
    The following directory shall exist on conforming systems and shall
    be used as described:

    /tmp
        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:

/etc/ovirt-engine/engine.conf.d/50-tmpdir.conf
---
ENGINE_PROPERTIES="-Djava.io.tmpdir=/var/tmp"
---

[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html

Comment 2 Lee Yarwood 2013-07-15 20:54:15 UTC
(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.

Thanks,

Lee

Comment 3 Alon Bar-Lev 2013-07-15 21:02:04 UTC
(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.

Comment 4 Michal Skrivanek 2013-07-29 13:09:53 UTC
fixing the loop should be enough, see bug 984491

*** This bug has been marked as a duplicate of bug 984491 ***