Support for arbitrary paths about whalebrew HOT 6 CLOSED

I'm going from the basic assumption that intent of whalebrew is that any "command you install from an image" will otherwise work as if it was installed natively.

From a security standpoint, my thought is that the best thing to do would be to create a /syncdir on each image, and then sync any paths in the exact same tree they resolve to on the host, only nested underneath /syncdir.

This means that whalebrew will need to evaluate any valid path expression, and map a container volume in the following container container:/syncdir/resolved/path to the according host volume: host:/resolved/path.

from whalebrew.

will need to evaluate any valid path expression

Exception would be if the path expression is passed explicitly as a string. ( some/path/dir would be given a host:container mount, but 'some/path/dir' would not).

from whalebrew.

@LongLiveCHIEF Sounds good! And presumably Whalebrew would then modify the argument, passing it fully resolved and prepended with /syncdir?

Some additional thoughts:

• I wonder if this is going to cause issues with commands which expect paths to be correct. e.g. tarballs with absolute filenames will be messed up
• Log messages to the user are going to have confusing paths in them
• I wonder if we can replace /workdir with this, too. Would be neat to just have a directory which is /hostfs or something, with specific files from the host mounted in their correct place.

from whalebrew.

I wonder if this is going to cause issues with commands which expect paths to be correct. e.g. tarballs with absolute filenames will be messed up

Can you give an example?

Log messages to the user are going to have confusing paths in them

Didn't consider that, but I wonder if we could use a stream transformer to strip any /syncdir references from stdout/stderr? I'm still getting familiar with the codebase, so this could be a completely valid, or completely absurd suggestion.

I wonder if we can replace /workdir with this, too. Would be neat to just have a directory which is /hostfs or something, with specific files from the host mounted in their correct place.

My gut says yes, but I think setting the workdir from the run command is going to be important, so we'd have to make sure to modify the -w param to prepend /hostfs or whatever we wind up calling it.

from whalebrew.

We'd also need to think through whether or not we could execute images that need access to host devices, and how any solution we create here might interfere with host device path mappings into the container.

Packer is a great example of this. For example, when I use the packer docker image to create a virtualbox iso, I need to mount -v /dev/vbox:/dev/vbox.

My guess is though, that we'd handle this using io.homebrew.volumes. (so I guess that would answer the question "should we keep the io.homebrew.volumes label support?)

from whalebrew.

Whalebrew could match arguments which look a bit like a path, then additionally mount those inside the container

I like the idea about reading the arguments, not about doing magic detection
Could an additional label "volumes-from-args"� do the job?

from whalebrew.