# Mounting-Local-Files

## Problem
Today adding scripts to your container to execute can be an annoying amount of work and a seemingly unnecessary step. For example, the following takes two steps:

$ ipfs add hello.R
added QmQRVx3gXVLaRXywgwo8GCTQ63fHqWV88FiwEqCidmUGhk hello.R
 20 B / 20 B [=====================================================================================================================================================] 100.00%

bacalhau docker run \
 -v QmQRVx3gXVLaRXywgwo8GCTQ63fHqWV88FiwEqCidmUGhk:/hello.R \
 r-base \
-- Rscript hello.R

To draw a parallel, in Docker, users can trivially “mount a volume” that allows access to a local directory. This enables a user to make a change outside the container and yet execute it in the container environment. This speeds REPL, and improves developer productivity.

However, this would only be done locally, meaning there were/are limited security concerns. The sensitive files never left your machine.

We could attempt something similar with a Bacalhau job, by allowing users to point at files or volumes and have them automatically upload. However, there are security concerns that need to be thought through. If someone turned on a flag, that would upload ALL files in that directory to a remote/untrusted machine. We need to work through both the UX and the security implications.

## Proposal
Support a new flag that allowed globbing files that should be mounted into a pre-defined directory.

bacalhau docker run --include-files hello.R r-base Rscript hello.R

Behind the scenes, this would gather all files identified by the command, tarball them up, and upload them into the container. This would NOT use IPFS or Filecoin to store the files (so that they aren't permanently out there). They could, for example, be put into a base64 encoded environment variable and mounted in the container itself.

Globs could also be supported. E.g.:

bacalhau docker run --include-files uploadfiles/*.R r-base Rscript hello.R

Questions:
* All files would be uploaded to the same directory?
* How do you deal with overwriting?
* Maintain execution bit? Security concern?
* Max limit for env variables?
* Attack vector - could you upload 10TB and crash the machine?
* What's the attack surface for untrusted nodes - they're already running code (today) so they could observe that - this is no different. What else?
* Do we support mounting in different volumes? Do we support uploading from different directories?
* Should the --include-files command be repeatable? eg `bacalhau docker run --include-files dir1/* --include-files dir2/* ...`
* Since we don't have to explicitly use the --context-upload flag in WASM, because it automatically uploads the scripts along with the contents of the PWD, but in the case of docker run we need to manually set the flag to upload the contents. there should be a common pattern used in both WASM and Docker backend

Other options:
* Encrypting and uploading to IPFS - still concerning that files would be out there forever
* Positive - it's just a CID and you mount it like normally.
* Positive - Could allow for reuse of existing CIDs (saving upload). **BUT** How do we diff? Would that be done locally?
* Upload to an HTTP endpoint and download?
* Auto upload using flags (e.g. if we detect a script in the command, we automatically upload it)
* e.g. `bacalhau docker run python-3.10-image myscript.py`
* **PROBLEM:** With a commands like the below, it would be very tough to tell what the files we want to auto-upload are and what are the named outputs

bacalhau docker run gcc-image gcc -o gentext gentext.c
bacalhau docker run gcc-image cc  -o mainprog -Llib -lmymath firstbit.c secondbit.o

* Other?

## Reuse of existing code
The WASM engine currently has functionality (which will be replaced) for its `--context-path`. This is an opportunity to combine efforts. We should not use the existing code, however, as it was proof of concept quality only.