only allow relative paths in `load_uploaded_files?

[soxofaan]

openeo-processes/proposals/load_uploaded_files.json

Lines 12 to 20 in 965bbae

	"name": "paths",
	"description": "The files to read. Folders can't be specified, specify all files instead. An exception is thrown if a file can't be read.",
	"schema": {
	"type": "array",
	"subtype": "file-paths",
	"items": {
	"type": "string",
	"subtype": "file-path",
	"pattern": "^[^\r\n\\:'\"]+$"

Current regex allows paths that escape the user workspace, like /etc/passwd and ../../etc/passwd.
Wouldn't it be cleaner to at least forbid absolute paths (starting with /)?

[m-mohr]

The file paths are not meant to be mapped to internal structures. The base path that should always be the user workspace, so I'd expect a folder/file.txt in the user workspace to be accessible via /folder/file.txt and folder/file.txt and ./folder/file.txt. A backend should ensure a user can never escape that base path. Maybe we need to clarify this further.

[soxofaan]

I'm also thinking about being future proof (e.g. loading files from another user), or allowing back-ends to go further than the official spec and workflows (e.g. supporting an out-of-band upload mechanism that uploads to something like /projects/ESA-123/data456.nc). If the standard regex is too liberal, there might be not enough wiggle room for these extensions.
That's why I'm suggesting to make sure the current standard only allows pure relative paths.

[m-mohr]

For other users, I'd rather use either a new parameter to select the data source or load_url. Encoding that in the path and as such exposing internals doesn't seem like a good idea. Similarly, if you have other data sources, or alternatively a new process.

[m-mohr]

I don't see a direct todo here, closing for now. If you think differently, please open a PR with a proposal.

[soxofaan]

A backend should ensure a user can never escape that base path. Maybe we need to clarify this further.

I think this is at least a todo here

[m-mohr]

PRs are welcome.