Allow absolute path in <directory> config

[marakiis]

Currently paths in the directory group of the config files are used as follow:
serverhome + value (value among in, out, work, arch, conf)
This prevent the use of absolute path in the value part of the configuration.
A solution would be to modify the getters of the configuration java like this:

public String getConfigPath() {
  File conf = new File(configPath);
  if (conf.isAbsolute()) {
    return configPath;
  }
  return getBaseDirectory() + configPath;
}

@fredericBregier what do you think ?

[fredericBregier]

Might lead to "chroot defect" if you apply this: one can specify another root path than the software based directory said.
Note that on Linux:

• Nothing prevents to mount specific FS for each directory (which is almost recommended indeed), giving the ability to separate each of them and manage them accordingly
• Nothing prevents too to make a symbolic link to the real directory (the right to do so is on adminsys responsability, in order to give the read/write access to the application user to them), so not giving issue such as "chroot defect"

On windows, the first is (as far as I know) not really possible (not simply at least), but the second works too.

WDYT?

[marakiis]

I understand and but what about preventing absolute path when loading the configuration ?
Just a check an throwing a BadConfigurationException if a "sub path" is absolute.

[fredericBregier]

OK, I got it.
I propose you to integrate this in 3.6.1 too (BadConfigurationException).
There will be several cases:

• Global configuration (where in, out, work...) are globally configured (xml information at startup)
• Rule configuration:
  • When defined (created or modified) (during admin intervention)
  • When used (if already defined) (during transfer initialization)

The first and second are ok for me. But perhaps the third (during transfer initialization) is too much?
I can imagine a scenario that will lead to an issue (a DBA change manually the rule directly in the database, so no control from the server OR the rule was already there before updating and therefore not changed but badly defined). But perhaps too much?
What I think, is that we can introduce a bad configuration during startup (global conf) or creation/modification of a rule through the server, but introducing such an exception during transfer could lead to ascending compatibility issue.

WDYT if I check only the 2 first cases, not the third one?

[fredericBregier]

@marakiis Done as requested (checks)