Bug 917765

Summary: If bundle destination path contains a symbolic link, relative paths specified in bundle recipe may resolve to incorrect parent
Product: [JBoss] JBoss Operations Network Reporter: Larry O'Leary <loleary>
Component: ProvisioningAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: medium    
Version: JON 3.1.2CC: ahovsepy, jkremser, lakagwu, lkrejci, myarboro
Target Milestone: ER01   
Target Release: JON 3.2.0   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1077387 (view as bug list) Environment:
Last Closed: 2014-01-02 20:35:19 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:
Bug Depends On:    
Bug Blocks: 1077387    
Attachments:
Description Flags
bundle-dest none

Description Larry O'Leary 2013-03-04 17:55:23 UTC
Description of problem:
When using rhq:file with a relative path for the destinationFile or destinationDir attribute, the relative path is resolved to an incorrect parent resulting in the file or directory being written or attempted to be written to the wrong place.

For example, if deploying a bundle to an EAP profile base location with a relative path specified in the recipe such as:

    <rhq:file name="app.properties" destinationFile="../../conf/app.properties" replace="false"/>

The expectation is the path will resolve to <JBOSS_HOME>/server/<JBOSS_PROFILE>/conf/app.properties. However, if <JBOSS_HOME>/server/<JBOSS_PROFILE>/deploy is a symbolic link to /var/local/jboss/eap/deploy, the relative path resolves to /var/local/jboss/eap/conf/app.properties. This results in the bundle's contents being written to the wrong location or failing to be deployed in the event that the resolved location is not writable by the user running the agent.

Version-Release number of selected component (if applicable):
4.4.0.JON312GA

How reproducible:
Always

Steps to Reproduce:
1.  Create a physical directory outside of EAP 5.x profile to hold contents of deploy:

        mkdir -p /tmp/eap/apps

2.  Move contents of EAP's <profile>/deploy directory to newly created location:

        mv ${JBOSS_HOME}/server/all/deploy /tmp/eap/apps/

3.  Create symbolic link in ${JBOSS_HOME}/server/all to /tmp/eap/apps/deploy:

        ln -s /tmp/eap/apps/deploy ${JBOSS_HOME}/server/all/deploy
        
4.  Start EAP 5.x server
5.  Start JBoss ON system
6.  Add EAP server to inventory
7.  Create bundle deployment using myBunlde.zip attachment 704238 [details]
8.  Deploy bundle to EAP server deploy.
    *   *Destination Name*: EAP Test Destination
    *   *Resource Group*: EAP servers
    *   *Base Location*: Profile Directory
    *   *Deployment Directory*: deploy/myapp.deployment

  
Actual results:
app.properties was deployed to /tmp/eap/apps/conf/

Expected results:
app.properties should be deployed to <JBOSS_HOME>/server/<JBOSS_PROFILE>/conf/

Additional info:
When resolving paths, it seems we should be using getCanonicalPath() or a method that properly handles the relative . and .. path elements as they relate to the parent path and not the symbolic destination.

Comment 1 Jirka Kremser 2013-03-06 10:56:45 UTC
In Java 7 api, there is a class [1] doing exactly what we need, i.e. resolving the ".." and "." in the path, without resolving the symlinks. If we decide not to be backward compatible with Java 6, we can use it.


[1] http://docs.oracle.com/javase/7/docs/api/java/nio/file/Path.html#normalize%28%29

Comment 3 Lukas Krejci 2013-06-27 22:03:52 UTC
In master (RHQ 4.9.0 codebase).

commit a8472635e28dcdc053e5d3d4a700d5cd8c60e752
Author: Lukas Krejci <lkrejci>
Date:   Thu Jun 27 23:46:34 2013 +0200

    [BZ 917765] - Symlinks in deploy dir no longer confuse relative file path
    
    if deployDir was:
    /opt/depls/target -> /opt/realdepls/realtarget
    (i.e. target was a symlink to realtarget)
    
    and a file was to be deployed to:
    ../conf/file
    
    a resulting path would be:
    opt/depls/target/../conf/file
    which would be resolved as:
    opt/realdepls/conf/file
    (i.e. the symlink would be resolved first and then the path would be
    normalized)
    
    This is not how people usually understand the paths and how they expect
    the bundle deployer to function.
    
    We therefore first manually normalize the path and only then obtain its
    absolute path to point to it during the deployment process.
    
    Notice that we no longer use the canonical paths anywhere in the deployer
    code.

Comment 4 Larry O'Leary 2013-09-06 14:31:53 UTC
As this is MODIFIED or ON_QA, setting milestone to ER1.

Comment 5 Armine Hovsepyan 2013-11-21 16:20:46 UTC
Created attachment 827335 [details]
bundle-dest

Comment 6 Armine Hovsepyan 2013-11-21 16:21:23 UTC
verified in er5 with scenario Larry described - screen-shot attached