add spec for exec a new process inside a container

This attempts to create a spec for execin process behavior for v1 container specification

Relevant to #286 

@crosbymichael @vishh @rjnagal feel free to take this over and change it if i'm missing somethings.
Would restricting access to cgroups via the filesystem solve the issue?
Privileged containers can still do anything they want.

On Thu, Dec 11, 2014 at 9:28 AM, Victor Marmol <notifications@github.com>
wrote:

> In SPEC.md
> <https://github.com/docker/libcontainer/pull/290#discussion-diff-21692525>
> :
>
> > +### Execute a new process inside of a running container.
> > +
> > +User can execute a new process inside of a running container. Any binaries to be
> > +executed must be contained within the container's rootfs.
> > +
> > +The started process is jailed inside the current container's rootfs. Any changes
> > +made by the process to the container's filesystem will be persisted after the
> > +process finished executing.
> > +
> > +The started process will join the container's existing namespaces. When the
> > +container is paused, the process will also be paused and will resume when
> > +the container is unpaused.  The started process will only run when the container's
> > +primary process (PID 1) is running, and will not be restarted when the container
> > +is restarted.
> > +
> > +The started process will have its own cgroups nested inside the container's
>
> You can always expose them inside as cAdvisor does today. We'll probably
> want to be able to expose them in the future as well to be able to use
> subcontainers. We had merged a PR for some time that put them in by
> default, I think we're closer to that world than the one where we don't let
> the users put the cgroup hierarchies in their container.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/docker/libcontainer/pull/290/files#r21692525>.
>