How VMAware Detects Container Environments Like Docker and Podman

VMAware detects Docker and Podman containers by checking for filesystem artifacts—specifically /.dockerenv, /.dockerinit, and /run/.containerenv—that these runtimes create exclusively inside containerized environments.

Container detection is a critical capability for virtualization analysis tools, allowing them to distinguish between bare-metal hosts and containerized workloads. The kernelwernel/vmaware library implements lightweight filesystem probes to reliably detect container environments without requiring privileged system calls. This article examines the specific implementation details of VMAware's Docker and Podman detection mechanisms as implemented in src/vmaware.hpp.

Docker Detection via Filesystem Artifacts

The dockerenv() Method

In src/vmaware.hpp at line 5606, the static method dockerenv() performs the Docker detection check. This function looks for two legacy marker files that the Docker Engine creates at the root of a container's filesystem.

The implementation uses util::exists() to check for the presence of /.dockerenv or the older /.dockerinit file:

[[nodiscard]] static bool dockerenv() {
    if (util::exists("/.dockerenv") || util::exists("/.dockerinit")) {
        return core::add(brand_enum::DOCKER);
    }
    return false;
}

When either file is detected, the method registers the Docker brand through core::add(brand_enum::DOCKER), which corresponds to the VM::DOCKERENV check enum. This adds the Docker brand to the internal result set that the CLI component later queries.

Podman Detection via Runtime Markers

The podman_file() Method at Line 6340

For Podman detection, VMAware employs the podman_file() static method located at line 6340 in src/vmaware.hpp. This function searches for /run/.containerenv, a file that Podman and other OCI-runtime-compatible tools create inside the container's runtime directory.

The detection logic follows the same lightweight pattern as Docker detection:

[[nodiscard]] static bool podman_file() {
    if (util::exists("/run/.containerenv")) {
        return core::add(brand_enum::PODMAN);
    }
    return false;
}

Upon finding /run/.containerenv, the function invokes core::add(brand_enum::PODMAN) to register the Podman brand, corresponding to the VM::PODMAN_FILE enum value documented in docs/documentation.md.

Brand Registration and CLI Integration

Both detection methods integrate with VMAware's generic brand detection framework. When core::add() receives a brand enum, it updates the internal state that the CLI component (src/cli.cpp) queries to produce human-readable output. The CLI maps brand_enum::DOCKER to "Docker" and brand_enum::PODMAN to "Podman" in the final report.

This architecture separates the detection logic from presentation, allowing the filesystem checks to remain lightweight while ensuring consistent branding across the tool's interfaces. According to the source code, these checks are designed to run without elevated privileges, relying solely on standard filesystem access.

Summary

• Docker detection relies on checking for /.dockerenv or /.dockerinit files via the dockerenv() method at line 5606 in src/vmaware.hpp.
• Podman detection identifies the /run/.containerenv marker file through the podman_file() method at line 6340 in the same header.
• Both methods use util::exists() for non-privileged filesystem checks and register brands via core::add() with specific brand_enum values.
• The detection results propagate to src/cli.cpp, which renders the container environment brands in the final output based on the VM::DOCKERENV and VM::PODMAN_FILE flags.

Frequently Asked Questions

What specific files does VMAware check to detect Docker?

VMAware checks for two specific files at the root filesystem: /.dockerenv and the legacy /.dockerinit. The dockerenv() method in src/vmaware.hpp uses util::exists() to probe for these Docker-specific artifacts, registering brand_enum::DOCKER when found.

How does VMAware differentiate between Docker and Podman containers?

VMAware uses distinct detection methods and brand enums for each runtime. Docker triggers brand_enum::DOCKER via the dockerenv() check, while Podman triggers brand_enum::PODMAN via the podman_file() check looking for /run/.containerenv. These are tracked as separate VM::DOCKERENV and VM::PODMAN_FILE flags in the internal result set.

Can these container detection methods be bypassed?

While a malicious actor with root access could delete /.dockerenv or /run/.containerenv, such modifications would break container tooling expectations and could be detected by other consistency checks. The current implementation prioritizes reliable detection over anti-tampering, as these files are standard OCI runtime markers documented in docs/documentation.md.

Where is the container detection logic implemented in VMAware?

All container detection logic resides in src/vmaware.hpp. The specific methods are dockerenv() at lines 5606-5609 and podman_file() at lines 6340-6344. The CLI presentation layer in src/cli.cpp consumes these detections to generate the final container environment report shown to users.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}