Mic92 / cntr

cntr Say no to in containers! is a replacement for that brings all your developers tools with you. This is done by mounting the file system from one container or the host into the target container by creating a nested container with the help of the Linux mount API. This allows to ship minimal runtime image in production and limit the surface for exploits. **Requirements**: Linux kernel 5.2 or later (uses fsopen/fsmount mount API, added in 5.2). Cntr was also published in Usenix ATC 2018. See bibtex for citation. **Note:** The academic paper describes the original FUSE-based architecture. As of version 2.0.0, cntr has been rewritten to use the Linux mount API instead of FUSE, significantly improving performance and security while maintaining the same user interface and capabilities. What you get **What this means for you:** • Use your familiar tools (vim, gdb, strace) even if they're not in the container • Access container files at , , etc. • Same network, process tree, and environment as the container • Original container keeps running normally - your changes only affect your session • Run native container commands with Demo In this two minute recording you learn all the basics of cntr: Features • For convenience cntr supports container names/identifier for the following container engines natively: • docker • podman • LXC • LXD • systemd-nspawn • containerd • k3s (via containerd/crictl) • For other container engines cntr also takes process ids (PIDs) instead of container names. Installation Cntr by design is only able to run on Linux. **System Requirements:** • Linux kernel 5.2 or later **For distribution packagers:** See PACKAGING.md for packaging guidelines and examples. Pre-build static-linked binary For linux x86_64 we build static binaries for every release. More platforms can added on request. See the release tab for pre-build tarballs. At runtime only commandline utils of the container engine in questions are required. Build from source All you need for compilation is rust + cargo. Checkout rustup.rs on how to get a working rust toolchain. Then run: Either: Or the latest master: For offline builds we also provided a tarball with all dependencies bundled here for compilation with cargo-vendor. Usage At a high-level cntr provides two subcommands: and : • : Allows you to attach to a container with your own native shell/commands. Cntr will mount the container at (configurable via environment variable). The container itself will run unaffected as the mount changes are not visible to container processes. • Example: where can be a container identifier or process id (see examples below). • : Run commands from the container filesystem. • Usage: • Example: where can be a container identifier or process id Since container commands might need their native mount layout at , chroots to the container and sets up the container's environment. **Note**: Cntr needs to run on the same host as the container. It does not work if the container is running in a virtual machine while cntr is running on the hypervisor. Docker 1: Find out the container name/container id: Either provide a container id... ...or the container name. To execute container native commands, use : You can also use Dockerfile from this repo to build a docker container with cntr: Podman See docker usage, just replace with the command. LXD 1: Create a container and start it 2: Attach to the container with cntr LXC 1: Create a container and start it 2: Attach to container with cntr: systemd-nspawn 1: Start container 2: Attach Generic process id The minimal information needed by cntr is the process id of a container process you want to attach to. In this case 17498 is the pid we are looking for. Containerd For containerd integration the binary is required. You can get a binary by running: Put the resulting binary in your 1: Start container 2: Attach It's also possible to run cntr from a container itself. This repository contains a example Dockerfile for that: In this example we attach to containerd by process id. The process id of a task is given in . To resolve containerd names one also would need to add the binary (~12mb) to the Dockerfile. Additional Config Custom Mount Directory By default, cntr mounts containers at . You can customize this location using the environment variable: This is particularly useful for: • Testing with temporary directories • Systems where is not suitable • Isolating multiple cntr sessions AppArmor Profile Control By default, cntr automatically inherits the AppArmor security profile from the target container. You can control this behavior using the flag: **When to use :** • Troubleshooting AppArmor-related issues • Running tools that conflict with the container's AppArmor profile • Systems where AppArmor is not properly configured • Development and debugging scenarios where you need unrestricted access **Note:** On systems without AppArmor enabled, this flag has no effect. The flag is available for both and commands. Running with File Capabilities (setcap) By default, cntr requires root privileges. However, you can use Linux file capabilities to run cntr without full root access: **Required capabilities:** | Capability | Purpose | |------------|---------| | | Namespace operations ( , ), mount operations | | | for command | | | Only needed when attaching to containers owned by a different user | **Why is required:** When Linux runs a binary with file capabilities, it marks the process as "non-dumpable" for security. This prevents the process from accessing , which cntr needs to function. Setting tells cntr to re-enable dumpable mode via . **Security considerations:** Enabling dumpable mode has security implications: • Core dumps may expose privileged memory contents • Other processes running as the same user can the cntr process The risk is mitigated by cntr's short-lived nature (attach → exec → exit), but you should understand these trad…