|
@@ -51,8 +51,20 @@ returns. The listing is not recursive: a node that wants a tree can walk it
|
|
|
itself, and recursion in the C++ layer is an unbounded loop driven by whatever
|
|
itself, and recursion in the C++ layer is an unbounded loop driven by whatever
|
|
|
is on disk.
|
|
is on disk.
|
|
|
|
|
|
|
|
-It honours the same path restrictions `fs.readFile` already applies, so this
|
|
|
|
|
-adds no new reach into the filesystem.
|
|
|
|
|
|
|
+It adds no new reach into the filesystem, though not for the reason one might
|
|
|
|
|
+assume: the `fs` API applies **no path restrictions at all** today.
|
|
|
|
|
+`readFile`, `writeFile`, `unlink` and `stat` each take an arbitrary absolute
|
|
|
|
|
+path and act on it with the runner process's own permissions. That is
|
|
|
|
|
+consistent with the platform's existing position - the `code` node runs
|
|
|
|
|
+arbitrary JavaScript and `process.exec` runs arbitrary commands, so a node
|
|
|
|
|
+author is already trusted completely - but it is worth stating plainly rather
|
|
|
|
|
+than implying a sandbox that does not exist. `readdir` follows the same rule as
|
|
|
|
|
+its neighbours and adds nothing new.
|
|
|
|
|
+
|
|
|
|
|
+Confining the `fs` API to configured roots would be a real improvement and is
|
|
|
|
|
+worth doing. It is deliberately not in this plan: it would change the behaviour
|
|
|
|
|
+of every existing node that touches the filesystem, and it deserves its own
|
|
|
|
|
+change rather than riding along inside a trigger batch.
|
|
|
|
|
|
|
|
## Part 2 - Webhook responses
|
|
## Part 2 - Webhook responses
|
|
|
|
|
|
