OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

I keep running into issues where different TOSCA service templates make different assumptions about path names in TOSCA ‘import’ statements:   ·          I have always assumed that all path names are relative (i.e. they start in the same directory of a repo or CSAR archive as the template that contains the ‘import’ statement). However, based on that assumption, it is not clear to me how I would specify an ‘absolute’ path name. ·          However, I also see templates that all path names are absolute (i.e. they always start at the root of a repo or CSAR archive) ·          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 think that ideally we should support both absolute and relative path names. Either way, I don’t think the spec clearly defines expected behavior so we need to clarify this.   We could adopt a ‘unix’ convention where absolute path names must start with a leading /   Alternatively, we could use something the Python convention, where all paths are considered absolute unless they start with a .    Thoughts?   Chris      

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.

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 XLAB d.o.o. / Pot za Brdom 100 / SI - 1000 Ljubljana / Slovenia tel.+386 40 556 755 / i nfo @xlab.si / www.x lab .si Project Manager, Platform and Systems Orchestration Member of OASIS TOSCA Standard Technical Committee Member of steampunk.si Google Drive / Linkedin / Twitter     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.

Hi Matej,                                                                

 
My apologies, I should have been more clear. When I talk about absolute paths , I mean absolute paths that start at the root of a repository (or CSAR), not
absolute paths on a PC or server. I m just looking for more elegant syntax than having to specify lots of statements that include ../

 
With respect to your comments, I think independent of where you specify absolute or relative paths, care must be taken to prevent specifying paths that traverse
outside of a repository or CSAR (for example, what happens if I include a import ../../../etc/passwd somewhere in my CSAR? Presumably my CSAR will get unzipped somewhere in the file system, and without some additional checks, I ll be able to navigate out
of the unzipped directory.
 
Chris
 


From: Matej ArtaÄ [mailto:matej.artac@xlab.si]

Sent: Thursday, October 17, 2019 9:43 PM
To: Chris Lauwers
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] relative vs. absolute path names in import statements


 
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
XLAB d.o.o. / Pot za Brdom 100 / SI - 1000 Ljubljana / Slovenia
tel.+386 40 556 755 / info@xlab.si /
www.xlab.si





Project Manager, Platform and Systems Orchestration
Member of OASIS TOSCA Standard Technical Committee
Member of
steampunk.si




Google Drive
/ Linkedin
/ Twitter




 
 



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.