Quoting Christian Seiler (christ...@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
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
