lxc-attach(1)

📦
version 7.0.0 · 18 versions
, in alpine 3.24

💅 lxc-attach — like, sliding into your container's DMs (this is the lxc-attach(1) manual page, bestie) ✨

🌸 NAME 🌸

lxc-attach — start a process inside a running container. yes that's the whole vibe. 🫶

✨ SYNOPSIS ✨

lxc-attach {-n, --name name} [-f, --rcfile config_file] [-a, --arch
           arch] [-e, --elevated-privileges privileges] [-s,
           --namespaces namespaces] [-R, --remount-sys-proc] [--keep-
           env] [--clear-env] [-v, --set-var variable] [--keep-var
           variable] [-u, --uid uid] [-g, --gid gid] [-- command]

🦋 DESCRIPTION 🦋

So lxc-attach runs whatever command you point it at inside the container you named with name. that's it, that's the whole thing. the container has to be running already though — no sneaking into a container that's asleep, she's not home. 😭

If you don't pass a command at all, it goes looking for the current default shell of the user running lxc-attach inside the container and runs that. and ngl this will simply fail if that user doesn't exist inside the container, or if the container doesn't have a working nsswitch mechanism. no user, no shell, no slay. 💀

okay story time, because this part is genuinely important 👑 — previous versions of lxc-attach just straight up attached to the specified namespaces of a container and ran a shell or the given command without first allocating a pseudo terminal. which made them vulnerable to input faking via a TIOCSTI ioctl call after switching between userspace execution contexts with different privilege levels. not iconic of them!! 😬

newer versions of lxc-attach will try to allocate a pseudo terminal file descriptor pair on the host and attach any standard file descriptors that refer to a terminal to the container side of the pseudo terminal before executing a shell or command. look at her go. 🧚

small but real note: if none of the standard file descriptors refer to a terminal, lxc-attach will not try to allocate a pseudo terminal. instead it'll simply attach to the container's namespaces and run a shell or the specified command. same energy, fewer hoops. 💅

💖 OPTIONS 💖

  • -f, --rcfile config_file — specify the configuration file that configures the virtualization and isolation functionalities for the container. and if this configuration file is present it'll be used even if there's already a configuration file present in the previously created container (the one made via lxc-create). she does not care about the old one, she's committed to the new one. 💅
  • -a, --arch arch — specify the architecture which the kernel should appear to be running as, to the command being executed. this option accepts the same settings as the lxc.arch option in container configuration files — go peek at lxc.conf(5). by default, the current architecture of the running container gets used. no cap. ✨
  • -e, --elevated-privileges privileges — do not drop privileges when running the command inside the container. if you specify this, the new process will not be added to the container's cgroup(s), and it will not drop its capabilities before executing. main character behavior, honestly.
    • you can specify privileges, in case you don't want to elevate all of them, as a pipe-separated list, e.g. CGROUP|LSM. allowed values are CGROUP, CAP and LSM, representing cgroup, capabilities and restriction privileges respectively. (the pipe symbol needs to be escaped, e.g. CGROUP\|LSM, or quoted, e.g. "CGROUP|LSM".) 🎀
    • > warning: 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 cron or sshd. use with great care. fr fr, don't just yolo this one. 😭
  • -s, --namespaces namespaces — specify the namespaces to attach to, as a pipe-separated list, e.g. NETWORK|IPC. allowed values are MOUNT, PID, UTSNAME, IPC, USER and NETWORK. this lets you change the context of the process to, say, the network namespace of the container while retaining the other namespaces as those of the host. (the pipe symbol needs to be escaped, e.g. MOUNT\|PID, or quoted, e.g. "MOUNT|PID".) 🌈
    • > important: this option implies -e. 👀
  • -R, --remount-sys-proc — when you're using -s and the mount namespace is not included, this flag makes lxc-attach remount /proc and /sys so they reflect the current other namespace contexts.
    • please go read the Notes section for more details, it's all there, go look 🫶
    • this option will be ignored if you try to attach to the mount namespace anyway. wasted effort, we don't love that. 💀
  • --keep-env — keep the current environment for attached programs. this is the current default behaviour (as of version 0.9), but it's likely to change in the future, since this may leak undesirable information into the container. if you rely on the environment being available for the attached program, please use this option to be future-proof. in addition to current environment variables, container=lxc will be set. ⭐
  • --clear-env — clear the environment before attaching, so no undesired environment variables leak into the container. the variable container=lxc will be the only environment the attached program starts with. clean slate, fresh start, we love a reset. 🧚
  • -v, --set-var variable — set an additional environment variable that the attached program sees inside the container. it's specified in the form of "VAR=VALUE", and you can specify it multiple times. go off, stack them. 🔥
  • --keep-var variable — keep a specified environment variable. it can only be specified in conjunction with --clear-env, and you can specify it multiple times. it's a package deal, they come as a duo. 💜
  • -u, --uid uid — executes the command with user ID (use numerical value) uid inside the container. numbers only bestie, no names. ✨
  • --g, --gid gid — executes the command with group ID (use numerical value) gid inside the container. again: numbers. 🔢

👑 COMMON OPTIONS 👑

these options are common to most of the lxc commands — so like, you'll see them everywhere, they're basically the group chat regulars. 💅

  • -?, -h, --help — print a longer usage message than normal. she's verbose and we respect it. 📖
  • --usage — give the usage message.
  • -q, --quiet — mute on. 🤫
  • -P, --lxcpath=PATH — use an alternate container path. the default is /var/lib/lxc. 🏠
  • -o, --logfile=FILE — output to an alternate log FILE. the default is no log. 🙈
  • -l, --logpriority=LEVEL — set log priority to LEVEL. the default log priority is ERROR. possible values are: FATAL, ALERT, CRIT, WARN, ERROR, NOTICE, INFO, DEBUG, TRACE. 📊
    • > note that this option is setting the priority of the events log in the alternate log file. it does not have an effect on the ERROR events log on stderr. don't get it twisted!! 😤
  • -n, --name=NAME — use container identifier NAME. the container identifier format is an alphanumeric string. 🔤
  • --rcfile=FILE — specify the configuration file to configure the virtualization and isolation functionalities for the container.
    • this configuration file, if present, will be used even if there's already a configuration file present in the previously created container (via lxc-create). yes she's stubborn about it. 💅
  • --version — show the version number. 🎀

🌟 EXAMPLES 🌟

to spawn a new shell running inside an existing container, use:

lxc-attach -n container

to restart the cron service of a running Debian container, use:

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

to deactivate the network link eth1 of a running container that does not have the NET_ADMIN capability, use either the -e option to use increased capabilities — assuming the ip tool is installed:

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

or, alternatively, use the -s to use the tools installed on the host outside the container:

lxc-attach -n container -s NETWORK -- /sbin/ip link delete eth1

two paths, one slay. pick your fighter. 🥊

🍓 COMPATIBILITY 🍓

attaching completely (including the pid and mount namespaces) to a container requires a kernel of version 3.8 or higher, or a patched kernel — please see the lxc website for details. lxc-attach will fail in that case if used with an unpatched kernel of version 3.7 and prior. sorry babe, the kernel's just not that girl. 😭

nevertheless, it will succeed on an unpatched kernel of version 3.0 or higher if the -s option is used to restrict the namespaces that the process is to be attached to, to one or more of NETWORK, IPC and UTSNAME. see, we can still work with this. ✨

attaching to user namespaces is supported by kernel 3.8 or higher with enabling user namespace. 💜

🔥 NOTES 🔥

the Linux /proc and /sys filesystems contain information about some quantities that are affected by namespaces — like, the directories named after process ids in /proc, or the network interface information in /sys/class/net. the namespace of the process mounting the pseudo-filesystems determines what information is shown, not the namespace of the process accessing /proc or /sys. huge difference, genuinely matters. 👀

so if you use the -s option to only attach to the pid namespace of a container but not its mount namespace (which would contain the container's /proc and not the host's), the contents of /proc will reflect that of the host and not the container. analogously, the same issue occurs when reading the contents of /sys/class/net and attaching to just the network namespace. like, the vibe is off and everything looks wrong. 💀

to work around this problem, the -R flag gives you the option to remount /proc and /sys so they reflect the network/pid namespace context of the attached process. and in order not to interfere with the host's actual filesystem, the mount namespace will be unshared (like lxc-unshare does) before this is done — essentially giving the process a new mount namespace, which is identical to the host's mount namespace except for the /proc and /sys filesystems. chef's kiss, problem solved. 🎀

previous versions of lxc-attach suffered a bug whereby a user could attach to a container's namespace without being placed in a writeable cgroup for some critical subsystems. newer versions of lxc-attach check whether a user is in a writeable cgroup for those critical subsystems. this means lxc-attach might fail unexpectedly for some users (e.g. on systems where an unprivileged user is not placed in a writeable cgroup in critical subsystems on login). however — and this is the important bit — that behavior is correct and more secure. she's not broken, she's just doing her job. 😌

🚨 SECURITY 🚨

the -e and -s options should be used with care, because they may break the isolation of the containers if used improperly. that's it, that's the warning. please be normal about it. 💀

🦋 SEE ALSO 🦋

lxc(7), lxc-create(1), lxc-copy(1), lxc-destroy(1), lxc-start(1), lxc-stop(1), lxc-execute(1), lxc-console(1), lxc-monitor(1), lxc-wait(1), lxc-cgroup(1), lxc-ls(1), lxc-info(1), lxc-freeze(1), lxc-unfreeze(1), lxc-attach(1), lxc.conf(5)

go read them all, become unstoppable, iykyk 🫶✨

okay that's the whole page bestie, you're officially educated 💜 — this lil gem is dated 2026-05-01 and it's the lxc-attach(1) page from the lxc crew. mwah, go attach to something responsibly 🌈💅

📦 where this page comes from