support command line mounting

[ianpark]

Currently runc has no option to create mount points from command line like Docker has "-v" option for that purpose. So it's quite difficult to integrate runc where -v option is used especially when we need to mount all the different paths every time for short-lived containers.
The only way is creating config.json every time with different mount point and delete it when container is terminated. Is it intended or can we consider adding that option?

[crosbymichael]

This has been omitted on purpose. There are a couple of reasons for this.

1. We want everything about the container and how it is created/run in the spec. This way when you type runc runc test the container is the same no matter where its running.
2. If have cli args for mount then we will have to end up putting many other things on the cli and it makes the spec less important and the information about how a container is created will be fragmented between the spec and what cli args a user passes.

There are probably a few more reasons that I am forgetting at the moment but hope this helps.

[cyphar]

In addition to what @crosbymichael said:

1. The API would be horrible if we wanted to provide the same features as the config specification (-v is already pretty nasty, and it doesn't even let you do anything other than bindmounts).
2. Mounting would be outside of the OCI specification, which would sort of break the purpose of the OCI (to standardise these APIs).
3. We already have hooks, which allow you to do any additional setup if you really wanted (though those might go away eventually) to. You could also manually do bindmounts by using runc create and runc start (do the bind mounts between the two calls).

Not to mention that I personally don't like docker run -v because it's not always clear what and how it's doing what it is doing. IMO Docker should only allow docker volume-style setup of volumes because then it's much easier to manage (docker run -v is a security hole waiting to happen).

[ianpark]

@crosbymichael @cyphar Thanks for the answer! Now I understand why -v is abandoned.
I need to mount dedicated directories (with random name) for each container, and currently using Docker with -v. But if -v could be an attack space, I also want to avoid it.
And it's quite interesting that you mentioned bindmounting between runc create and runc start.
Could you share a bit of knowledge how to do that? if it's running a mount command, where could be the "destination"? Thanks for your help in advance!

[crosbymichael]

@ianpark its not an attack space. Containers are as secure as the people operating them. If you bind mount your / then of course its not going to be as secure but what would one expect. ;) Its has nothing to do with -v but bind mounts in general.

As far as solving your random dir mount issue, the mounts struct for binds does support relative paths so you can make this directory inside your bundle and have runc mount it.

[ianpark]

@crosbymichael Many thanks. what I need to do is, read-only binding of a directory where a input file is stored. Input files must be stored in separate directories for each task to prevent any possible interference. Each input file is confidential so must not be visible by the other container. The location of the file is like:
/var/tmp/usr_input/<UUID(created randomly and dynamically)>/input.dat
An unsafe application runs in the container and reads the input file to produce output. The original input path must be hidden in the container so I bind like below in Docker:
/var/tmp/user_input/:/user_input:ro
So the unsafe application is always able to read the input file from "/user_input" safely, but unable to access the other input files or to change the input file.

Is your suggestion creating config.json in each random directory and run "runc" in there?
It's a good idea but I prefer not to create multiple temporal config.json files. Do you think the idea @cyphar suggested in his comment is also feasible?

[cyphar]

@ianpark There are a couple of ways you can do it. You can create ethereal config.jsons (which is how I would recommend doing it). Another method would be (assuming that processes inside the container are not running as root) to create a post-mount hook that hard links the file into the container (with the file mode set so that the user in the container can only read, but not write, the file). I wouldn't really recommend the second one because it makes your container setup depend on trivial external components -- but if this works for you then have at it. 😉

[ianpark]

@cyphar Thanks for the clarification! ;-) You and @crosbymichael have helped me out a lot!
I think the dynamically generating config.json sounds like the best solution for my use case.

The one downside is I cannot put the multiple config.json files on the same directory as runc does not allow me to set a custom config file name. It may be useful to have the option, or to upgrade the -b option to grab the json file name if it's provided. Or is not supporting custom config file name also by design?

Regards,

Ian

[hqhq]

It's in the spec that the config has to be named config.json, if you want options to customize your runc config, it should be ocitools to do this job, though I'm not sure if it's capable for your bind mount customization for now.

[cyphar]

One important thing to note (which @hqhq touched on) is that all of the design decisions that happen inside runC are backed by the OCI runtime specification. So, if you want to discuss and change components of runC's design, you'll probably want to make issues against there (though we do welcome that discussion here, the runtime-spec repo is a more appropriate place to discuss changing the design of runC's user-facing API).

[ianpark]

@hqhq @cyphar many thanks guys! sorry for ignorant questions :-) I will have a look at the spec repo.

[cyphar]

Not to worry. Questions are never a bad thing, and there's rarely such a thing as a truly stupid question.

[ringerc]

While I realise this is old, I'd like to point out a possible use case for command-line mounts, and that's dynamic mounting of additional volumes after container start for diagnostic purposes.

That'd be something outside the OCI spec itself, as it's mutating an existing container.

For example, injecting a mount containing a shell and diagnostic tools into an already-running os-less container so that interactive analysis is possible from within the container's pid and mount namespaces.