bundle relative paths using ".."

John Mazzitelli mazz at redhat.com
Fri Apr 26 00:37:17 UTC 2013


Someone opened up a pandora's box with this one: https://bugzilla.redhat.com/show_bug.cgi?id=917085

Title: "Relative paths to rhq:file element fail if parent deploy destination has not yet been created"

I need to solicit opinions, because this is now my second night wallowing in this code wondering how I should handle it, if I should at all.

Here's the crux of the problem:

Someone wrote a bundle recipe and wants to write a bundle file to a location specified via a relative path (thus, relative to the bundle destination directory) - the problem is the relative path used "..":

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

Now, look at the problem this poses. This file is no longer going to be placed UNDER the bundle destination directory! The author of the recipe is actually asking us to put the file outside. So we have a relative path that is supposed to be under the destination directory, but it really isn't.

Technically, this is possible - today, you can do this via absolute paths:

   <rhq:file name="app.properties" destinationFile="/opt/jboss/conf/app.properties" />

Because the earlier path was a relative path, we assume its under the destination directory and we do things accordingly - if it really isn't under the dest dir, things break. I tried converting these "relative" paths that have ".." in them to be absolute, canonical paths, but that ends up breaking other things, specifically, problems occur if the relative path ends up NOT outside of the dest dir (i.e. it is now the opposite problem):

   <rhq:file name="app.properties" destinationFile="some-location/subdir/../file.txt" />

So, unless I write special code to handle these different scenarios, things break all over.

My question - should we allow for relative paths in the recipe that use ".."?

Rather than use relative path, the user could either:

1) use an absolute path if its known (rather than say ../../conf/app.properties, say "/opt/jboss/server/default/conf/app.properties" - this assumes you know your app server is in /opt/jboss)
2) deploy the bundle with a destination directory of the top most directory you need, and your relative paths no longer need ".." (rather than say ../../conf/app.properties, your dest directory should be the jboss install dir and your relative path then becomes "server/default/conf/app.properties")

If we do not allow relative paths to have ".." in them, what problems does this cause? I see some myself - it probably isn't user-friendly to not allow them to do this, and it requires the user to know the dest dir IN the recipe (in order to put an absolute path in, they need to know the full path, which includes dest dir), which goes against the design of what we want people to be able to do in recipes.

I could opt for some hybrid approach - I wrote up some code that is working but ONLY if the relative path using ".." takes the file outside of the dest dir - if the relative path has ".." but stays under the dest dir, other odd things happen. But then, why specify a path like that in the first place? Seems odd - when would you ever want to say something like destinationFile="some-location/subdir/../file.txt" ?

Sorry for the rambling... if you understand any of this, chime in with thoughts.


More information about the rhq-devel mailing list