Hello Chris,
when it comes to paths, Iâd advise some caution regarding the absolute paths. Allowing for absolute paths is useful in the use cases where the user has a full control over the workstation. But once we envision the orchestrator running as a service, taking in third party TOSCA content, it is prudent to restrict the paths in imports and artifacts to relative paths only. Otherwise some black hat would be quick to import that /etc/passwd into an environment that they control on the host that they do not.
In our orchestrator, we plan to reject absolute links and allow operation within the CSAR only. Of course this does not prevent us from having some sort of a pre-processor that would still take in a service template or a CSAR that uses absolute paths, but then copies or blocks content at its own discretion. Or perhaps include a command line switch that enables the unsafe mode.
Best regards,
Matej
|
Matej ArtaÄ, Ph.D. / Project Manager |
Project Manager, Platform and Systems Orchestration Member of OASIS TOSCA Standard Technical Committee Member of steampunk.si |
From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Tal Liron
Sent: Friday, October 18, 2019 12:36 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] relative vs. absolute path names in import statements
On Thu, Oct 17, 2019 at 5:11 PM Chris Lauwers <lauwers@ubicity.com> wrote:
I keep running into issues where different TOSCA service templates make different assumptions about path names in TOSCA âimportâ statements:
Why not just use the URL specification? It includes specifications for both relative and absolute locations. For an absolute filesystem path it could be "file://" or "http://", for example. Relative paths (without the schema) would be relative to the URL of the current document. This is how I handled it without too much difficulty in Puccini. This also avoid confusion with the Windows forward slash for path separation -- the URL spec uses backslashes.
This would also assist implementations, because practically every language has either built-in support for URLs or good libraries to handle them.
 Aside from âimportâ statements, how do we deal with other aspects of the TOSCA syntax that rely on path names, e.g. path names to specify an âartifactâ in a repo?
I agree entirely -- whatever spec we choose, it should be the same for all paths in TOSCA, including artifact locations.