Expose stdin, just like stdin and stderr, through to CloudABI YAML configuration files, so that REPL programs can be built with CloudABI.

Workaround for UNIX hosts:

%TAG ! tag:nuxi.nl,2015:cloudabi/
---
console_out: !fd stdout
console_err: !fd stderr
console_in: !file
    path: /dev/tty

Our users will likely store some sensitive information in the CloudABI YAML configuration files, such as passwords and tokens. Let's assume stdin is enabled and some kind of output stream such as a network port or output file. Would it be possible for a malicious or poorly written CloudABI application to seek backwards and read the configuration content, later leaking this information?

Just a wild idea: I think it could be useful to be able to launch multiple cloudabi programs at the same time, with pipes connecting to each other. Possibly configured from a single YAML file, which also specifies the topology.

This would make it easier to sandbox separate concerns in separate sub-programs. E.g. a process that stores keys, a process that handles incoming network connections, and so on.

Edit: Alternatively I guess this could be handled by having a top-level cloudabi executable that connects and launches the subprograms. However the user would need to give it access to the directory with the binaries. Or pass it pre-opened file-descriptors to the binaries. Yes that would work I guess, with execveat with AT_EMPTY_PATH.

I am trying to wedge stdin as a file descriptor, so that my CloudABI program an act as a REPL. Am I using argdata / YAML syntax correctly?

Source

https://github.com/mcandre/tonixxx/tree/issue-115/examples/fewer

Configuration

$ cat cloudabi.yml 
%TAG ! tag:nuxi.nl,2015:cloudabi/
---
console_out: !fd stdout
console_err: !fd stderr
console_in: !fd 3
file: !file
    path: README.md

Trace

$ cloudabi-run bin/fewer <cloudabi.yml 3</dev/stdin
yaml-cpp: error at line 5, column 13: XXX!

cloudabi-run (running in the Posix world) can't set all Capsicum rights properly on the file descriptors it opens. It'll have to ask cloudabi-reexec (running in the CloudABI world) to disable some rights on the file descriptors it gets, if that was originally specified in the Yaml file.

Right now, cloudabi-exec takes an argdata sequence of two items: The file descriptor of the executable to run, and the argdata to provide to that program.

We could simply add an (optional) third item to that sequence, which describes what rights the file descriptors should have. This could be a map, mapping file descriptors to a 2-tuple (sequence) containing (fs_rights_base, fs_rights_inheriting), both as integers.

Could we add some basic command line tests for cloudabi-run and so on, to ensure that the utilities match the advertised capabilities as described in the man pages?

https://gitlab.kitware.com/cmake/community/wikis/doc/ctest/Testing-With-CTest

I see a TODO for this; I'm opening this issue as a way of registering interest and subscribing to progress. I think I need it for https://github.com/dckc/ZeroV

  if (tag == "tag:nuxi.nl,2015:cloudabi/file") {
    // Open a file by pathname.
    // TODO(ed): Make mode and rights adjustable.

-- https://github.com/NuxiNL/cloudabi-utils/blob/master/src/cloudabi-run/yaml_file_descriptor_factory.cc#L74-L76

I want to install the latest commit of cloudabi-utils via Homebrew, but unfortunately the current formula does not declare where the master branch is :/

Please show examples for how to configure directory and flat file paths, such as with read-only, write-only, and read-write, append, replace, byte, and text modes.

Hey, I'm using valgrind to scan my CloudABI programs for any memory leaks. The good news is, my short example programs appear to be clearing their heap fairly well. The bad news is, our runtime appears to leave a few bytes hanging when exit() runs.

Now, this is not exactly critical, but it does muddy the water when programmers are trying to make sense of the valgrind output.

Source

https://github.com/mcandre/tonixxx/tree/issue-115/examples/fewer

Trace

$ valgrind --error-exitcode=1 --leak-check=full cloudabi-run -e bin/fewer <cloudabi-unittest.yml
==1305== Memcheck, a memory error detector
==1305== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1305== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1305== Command: cloudabi-run -e bin/fewer
==1305== 
WARNING: Attempting to start executable using emulation.
Keep in mind that this emulation provides no actual sandboxing.
Though this is likely no problem for development and testing
purposes, using this emulator in production is strongly
discouraged.
==1305== 
==1305== HEAP SUMMARY:
==1305==     in use at exit: 23,703 bytes in 158 blocks
==1305==   total heap usage: 6,754 allocs, 6,596 frees, 181,227 bytes allocated
==1305== 
==1305== LEAK SUMMARY:
==1305==    definitely lost: 0 bytes in 0 blocks
==1305==    indirectly lost: 0 bytes in 0 blocks
==1305==      possibly lost: 0 bytes in 0 blocks
==1305==    still reachable: 23,703 bytes in 158 blocks
==1305==         suppressed: 0 bytes in 0 blocks
==1305== Reachable blocks (those to which a pointer was found) are not shown.
==1305== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==1305== 
==1305== For counts of detected and suppressed errors, rerun with: -v
==1305== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Could we clear up these hanging blocks, so that programmers see only their particular application's leaks?

As a newbie, I want cloudabi-run to automatically look for any keys named stderr, stdout, or stdin in the CloudABI configuration and remap such streams to the new file descriptors, such as with dup2(). So that our users can conveniently continue to access assert(), printf(), etc., without having to write custom logic to set this up for each application.

Okay, I see that cloudlibc provides dup2(), however this is not particularly useful for remapping stderr and friends, without also defining STDERR_FILENO, STDOUT_FILENO, and STDIN_FILENO. Could we declare these like -2, -3, -4, so that we can refer to them for remapping?

Would be great to expose command line argument configuration to CloudABI processes, so that more dynamic configuration can be used. For example, a CloudABI-enabled ls would want to be able to accept file paths. A CloudABI-enabled nc would want to accept port numbers.

As a workaround, users can write wrapper scripts to generate different cloudabi YAML configurations based on the CLI arguments. But it would be much better to have cloudlibc and cloudabi-utils provide this out of the box!