Bug 984503 - Incorrect permissions against /tmp can result in looping OvfWriter failures
Incorrect permissions against /tmp can result in looping OvfWriter failures
Status: CLOSED DUPLICATE of bug 984491
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.2.0
All Linux
medium Severity medium
: ---
: 3.3.0
Assigned To: Michal Skrivanek
virt
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-15 07:55 EDT by Lee Yarwood
Modified: 2015-09-22 09 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-29 09:09:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 405253 None None None Never

  None (edit)
Description Lee Yarwood 2013-07-15 07:55:18 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

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 13:50:41 EDT
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 16:54:15 EDT
(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 17:02:04 EDT
(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 09:09:53 EDT
fixing the loop should be enough, see bug 984491

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

Note You need to log in before you can comment on or make changes to this bug.