<!DOCTYPE refentry PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [

<!ENTITY commonoptions SYSTEM "@builddir@/common_options.sgml">

<!ENTITY seealso SYSTEM "@builddir@/see_also.sgml">

]>

<refentry>

<docinfo><date>@LXC_GENERATE_DATE@</date></docinfo>

<refmeta>

<refentrytitle>lxc-attach</refentrytitle>

<manvolnum>1</manvolnum>

</refmeta>

<refnamediv>

<refname>lxc-attach</refname>

<refpurpose>

start a process inside a running container.

</refpurpose>

</refnamediv>

<refsynopsisdiv>

<cmdsynopsis><command>lxc-attach <replaceable>-n

name</replaceable> <optional>-a

arch</optional> <optional>-e</optional>

<optional>-- command</optional></command></cmdsynopsis>

</refsynopsisdiv>

<refsect1>

<title>Description</title>

<para>

<command>lxc-attach</command> runs the specified

<replaceable>command</replaceable> inside the container

specified by <replaceable>name</replaceable>. The container

has to be running already.

</para>

<para>

If no <replaceable>command</replaceable> is specified, the

current default shell of the user running

<command>lxc-attach</command> will be looked up inside the

container and executed. This will fail if no such user exists

inside the container or the container does not have a working

nsswitch mechanism.

</para>

</refsect1>

<refsect1>

<title>Options</title>

<variablelist>

<varlistentry>

<term>

<option>-a, --arch <replaceable>arch</replaceable></option>

</term>

<listitem>

<para>

Specify the architecture which the kernel should appear to be

running as to the command executed. This option will accept the

same settings as the <option>lxc.arch</option> option in

container configuration files, see

<citerefentry>

<refentrytitle><filename>lxc.conf</filename></refentrytitle>

<manvolnum>5</manvolnum>

</citerefentry>. By default, the current archictecture of the

running container will be used.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term>

<option>-e, --elevated-privileges</option>

</term>

<listitem>

<para>

Do not drop privileges when running

<replaceable>command</replaceable> inside the container. If

this option is specified, the new process will

<emphasis>not</emphasis> be added to the container's cgroup(s)

and it will not drop its capabilities before executing.

</para>

<para>

<emphasis>Warning:</emphasis> This may leak privileges into the

container if the command starts subprocesses that remain active

after the main process that was attached is terminated. The

(re-)starting of daemons inside the container is problematic,

especially if the daemon starts a lot of subprocesses such as

<command>cron</command> or <command>sshd</command>.

<emphasis>Use with great care.</emphasis>

</para>

</listitem>

</varlistentry>

</variablelist>

</refsect1>

&commonoptions;

<refsect1>

<title>Examples</title>

<para>

To spawn a new shell running inside an existing container, use

<programlisting>

lxc-attach -n container

</programlisting>

</para>

<para>

To restart the cron service of a running Debian container, use

<programlisting>

lxc-attach -n container -- /etc/init.d/cron restart

</programlisting>

</para>

<para>

To deactivate the network link eth1 of a running container that

does not have the NET_ADMIN capability, use the <option>-e</option>

option to use increased capabilities:

<programlisting>

lxc-attach -n container -e -- /sbin/ip link delete eth1

</programlisting>

</para>

</refsect1>

<refsect1>

<title>Security</title>

<para>

The <option>-e</option> should be used with care, as it may break

the isolation of the containers if used improperly.

</para>

</refsect1>

&seealso;

<refsect1>

<title>Author</title>

<para>Daniel Lezcano <email>daniel.lezcano@free.fr</email></para>

</refsect1>

</refentry>