IPC Endpoint Path Generation in collector-core#

collector-core generates Inter-Process Communication (IPC) endpoint paths using a secure, platform-aware mechanism that ensures both security and test isolation. The approach differs slightly between production and testing environments, and between Unix and Windows platforms.

Mechanism Overview#

When initializing an IPC server, collector-core calls a function to create the endpoint path. On Unix systems, this function creates a secure temporary directory (using the tempfile crate) with a daemoneye- prefix. The socket file is then placed inside this directory. In production, the socket name includes a UUID to guarantee uniqueness; in tests, a shorter name derived from the process ID is used to avoid exceeding Unix socket path length limits (SUN_LEN). If the generated path is too long, the system falls back to a short name like s.sock within the temporary directory. On Windows, the endpoint is a named pipe with a unique suffix, such as \\.\pipe\daemoneye\collector-{unique_id}. The temporary directory handle is retained for the server's lifetime to ensure the socket remains accessible and is cleaned up automatically when the server shuts down [source].

Secure Temporary Directories and Unique Socket Names#

For testing, collector-core always generates a new temporary directory and a unique socket name for each test run. This is achieved by using the process ID modulo 10000 as part of the socket name, which keeps the path short and unique. The use of temporary directories ensures that each test has its own isolated environment, preventing interference between concurrent or repeated test runs. The temporary directory is created with permissions set to 0700, and the socket file itself is set to 0600, restricting access to the owner only [source].

Rationale and Security Implications#

This design provides several benefits:

• Security: By placing sockets in directories with restrictive permissions and using owner-only socket files, unauthorized access is prevented. The IPC system is strictly local, with no network exposure, further reducing the attack surface [source].
• Reliability: Unique socket names and isolated directories prevent collisions and ensure that sockets are cleaned up automatically, reducing the risk of stale or orphaned sockets causing failures in subsequent runs.
• Test Isolation: Each test run operates in its own temporary directory with a unique socket, eliminating cross-test interference and making tests more reliable and reproducible [source].

Customizing IPC Endpoint Paths#

While the default behavior is to generate endpoint paths automatically, users can customize the IPC endpoint path via configuration. The IPC configuration structure (IpcConfig) includes an endpoint_path field. You can set this field programmatically or via a configuration file.

Example YAML configuration:

ipc:
  endpoint_path: "/tmp/custom-daemoneye.sock" # Unix/macOS
  # OR
  endpoint_path: "\\\\.\\pipe\\custom-daemoneye" # Windows

This allows you to specify a fixed location for the IPC socket or named pipe if needed for integration with other components or for debugging purposes [source].

Programmatic configuration example (Rust):

let config = IpcConfig {
    endpoint_path: "/tmp/my-custom.sock".to_string(),
    // ... other fields ...
};

Summary Table#

Additional Reliability Features#

The IPC system also supports automatic reconnection with exponential backoff, connection limiting, and configurable timeouts, further improving robustness in both production and test environments [source].

For more details, see the collector-core IPC implementation and the technical documentation.