[lxc-devel] [PATCH 5/5] lxc-attach: Completely rework lxc-attach and move to API function

[Serge Hallyn]

Quoting Christian Seiler (christian at iwakd.de):
>  - Move attach functionality to a completely new API function for
>    attaching to containers. The API functions accepts the name of the
>    container, the lxcpath, a structure indicating options for attaching
>    and returns the pid of the attached process. The calling thread may
>    then use waitpid() or similar to wait for the attached process to
>    finish. lxc-attach itself is just a simple wrapper around the new
>    API function.
> 
>  - Use CLONE_PARENT when creating the attached process from the
>    intermediate process. This allows the intermediate process to exit
>    immediately after attach and the original thread may supervise the
>    attached process directly.
> 
>  - Since the intermediate process exits quickly, its only job is to
>    send the original process the pid of the attached process (as seen
>    from outside the pidns) and exit. This allows us to simplify the
>    synchronisation logic by quite a bit.
> 
>  - Use O_CLOEXEC / SOCK_CLOEXEC on (hopefully) all FDs opened in the
>    main thread by the attach logic so that other threads of the same
>    program may safely fork+exec off. Also, use shutdown() on the
>    synchronisation socket, so that if another thread forks off without
>    exec'ing, the synchronisation will not fail. (Not tested whether
>    this solves this issue.)
> 
>  - Instead of directly specifying a program to execute on the API
>    level, one specifies a callback function and a payload. This allows
>    code using the API to execute a custom function directly inside the
>    container without having to execute a program. Two default callbacks
>    are provided directly, one to execute an arbitrary program, another
>    to execute a shell. The lxc-attach utility will always use either
>    one of these default callbacks.
> 
>  - More fine-grained control of the attached process on the API level
>    (not implemented in lxc-attach utility yet, some may not be sensible):
>      * Specify which file descriptors should be stdin/stdout/stderr of
>        the newly created process. If fds other than 0/1/2 are
>        specified, they will be dup'd in the attached process (and the
>        originals closed). This allows e.g. threaded applications to
>        specify pipes for communication with the attached process
>        without having to modify its own stdin/stdout/stderr before
>        running lxc-attach.
>      * Specify user and group id for the newly attached process.
>      * Specify initial working directory for the newly attached
>        process.
>      * Fine-grained control on whether to do any, all or none of the
>        following: move attached process into the container's init's
>        cgroup, drop capabilities of the process, set the processes's
>        personality, load the proper apparmor profile and (for partial
>        attaches to any but not mount-namespaces) whether to unshare the
>        mount namespace and remount /sys and /proc. If additional
>        features (SELinux policy, SMACK policy, ...) are implemented,
>        flags for those may also be provided.
> ---
>  src/lxc/attach.c     |  495 +++++++++++++++++++++++++++++++++++++++++++++++++-
>  src/lxc/attach.h     |   89 +++++++++
>  src/lxc/lxc_attach.c |  407 +++--------------------------------------
>  3 files changed, 608 insertions(+), 383 deletions(-)

Thanks, I'm still looking, but so far it looks good.

Note though when I was talking about putting attach "into the API",
I meant by that adding a lxcapi_attach() function to struct
lxc_container in src/lxc/lxccontainer.{c,h} that python/go/lua can
then call into.  That should be trivial to do on top of what you have
here.  Were you going to send a patch for that, or would you prefer I
just do it?

thanks,
-serge