DEV Community: mohamed alaaeldin

Ethical Implications of IP Spoofing: A Technical Examination for Security Practitioners

mohamed alaaeldin — Fri, 14 Mar 2025 18:16:00 +0000

Introduction

IP spoofing, the practice of forging source IP addresses in network packets, straddles a fine line between legitimate tool and malicious weapon. While its applications in penetration testing and network diagnostics are invaluable, its abuse in DDoS attacks, session hijacking, and evasion tactics underscores its dual-edged nature. This article dissects the technical mechanics of IP spoofing, provides a refined code example for educational purposes, and emphasizes the ethical obligations of practitioners.

The Anatomy of IP Spoofing

At its core, IP spoofing involves manually crafting packet headers to mask the sender’s true origin. This bypasses naive IP-based trust models and can obfuscate attack footprints. Key risks include:

DDoS Amplification: Spoofed requests to reflection services (e.g., DNS, NTP) flood targets with traffic.
Impersonation Attacks: Trusted IPs grant unauthorized access to restricted systems.
Data Interception: Spoofed ARP or TCP packets enable man-in-the-middle exploits.

Defenses like BCP38 (Ingress Filtering) and cryptographic authentication (e.g., IPsec) mitigate these risks, but understanding offensive tactics remains critical for robust defense.

Ethical Imperatives

Authorization is non-negotiable. Unauthorized spoofing violates laws like the Computer Fraud and Abuse Act (CFAA) in the U.S. and analogous statutes globally. Ethical use cases include:

Controlled Penetration Testing: Simulate attacks to audit network resilience.
Research: Study protocol vulnerabilities (e.g., TCP sequence prediction).
Load Balancer Testing: Validate stateless service behavior under spoofed traffic.

Always operate within sandboxed environments or networks where explicit consent is obtained.

Technical Deep Dive: Crafting a Spoofed TCP Packet

Below is a refined C++ implementation demonstrating IP/TCP packet crafting. Key improvements include IP checksum calculation, stricter error handling, and modularity.

#include <iostream>
#include <cstring>
#include <stdexcept>
#include <unistd.h>
#include <arpa/inet.h>
#include <netinet/ip.h>
#include <netinet/tcp.h>
#include <sys/socket.h>

// Pseudo-header for TCP checksum (RFC 793)
struct pseudo_header {
    uint32_t src_addr;
    uint32_t dest_addr;
    uint8_t reserved;
    uint8_t protocol;
    uint16_t tcp_len;
};

// Compute 16-bit one's complement checksum
uint16_t compute_checksum(uint8_t* data, uint32_t len) {
    uint32_t sum = 0;
    for (; len > 1; len -= 2) {
        sum += (data[0] << 8) | data[1];
        data += 2;
    }
    if (len == 1) {
        sum += static_cast<uint16_t>(*data) << 8;
    }
    while (sum >> 16) {
        sum = (sum & 0xFFFF) + (sum >> 16);
    }
    return static_cast<uint16_t>(~sum);
}

int main() {
    // Require root privileges for raw socket access
    if (getuid() != 0) {
        throw std::runtime_error("Root access required (CAP_NET_RAW)");
    }

    // Create raw socket (manual IP header construction)
    int sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW);
    if (sock < 0) {
        throw std::runtime_error(std::string("Socket error: ") + strerror(errno));
    }

    // --- IP Header Configuration ---
    struct iphdr ip;
    ip.ihl = 5;                     // Header length (5 * 32-bit words)
    ip.version = 4;                  // IPv4
    ip.tos = 0;                      // Default TOS
    ip.tot_len = htons(sizeof(iphdr) + sizeof(tcphdr) + 12); // IP + TCP + 12B payload
    ip.id = htons(54321);            // Identification
    ip.frag_off = 0;                 // No fragmentation
    ip.ttl = 64;                     // Time-to-live
    ip.protocol = IPPROTO_TCP;       // Upper-layer protocol
    ip.saddr = inet_addr("192.168.0.101"); // Spoofed source
    ip.daddr = inet_addr("192.168.0.102"); // Target destination

    // Calculate IP checksum (kernel does NOT do this for IPPROTO_RAW)
    ip.check = compute_checksum(reinterpret_cast<uint8_t*>(&ip), sizeof(iphdr));

    // --- TCP Header Configuration ---
    struct tcphdr tcp;
    tcp.source = htons(12345);       // Spoofed source port
    tcp.dest = htons(80);            // HTTP port
    tcp.seq = htonl(1000);           // Initial sequence number
    tcp.ack_seq = 0;                 // ACK not set
    tcp.doff = 5;                    // TCP header length (5 * 32-bit words)
    tcp.syn = 1;                     // SYN flag (initiate connection)
    tcp.window = htons(5840);         // Receive window
    tcp.check = 0;                   // Temporarily zero (calculated later)
    tcp.urg_ptr = 0;

    // Payload (SYN packets typically have no payload; added for demonstration)
    const char* payload = "Hello, TCP!";
    uint32_t payload_len = strlen(payload);

    // --- TCP Checksum Calculation (requires pseudo-header) ---
    pseudo_header psh;
    psh.src_addr = ip.saddr;
    psh.dest_addr = ip.daddr;
    psh.reserved = 0;
    psh.protocol = IPPROTO_TCP;
    psh.tcp_len = htons(sizeof(tcphdr) + payload_len);

    // Construct temporary buffer for checksum computation
    uint32_t psize = sizeof(pseudo_header) + sizeof(tcphdr) + payload_len;
    uint8_t* buffer = new uint8_t[psize];
    memcpy(buffer, &psh, sizeof(pseudo_header));
    memcpy(buffer + sizeof(pseudo_header), &tcp, sizeof(tcphdr));
    memcpy(buffer + sizeof(pseudo_header) + sizeof(tcphdr), payload, payload_len);

    tcp.check = compute_checksum(buffer, psize);
    delete[] buffer;

    // --- Assemble Final Packet ---
    uint8_t packet[sizeof(iphdr) + sizeof(tcphdr) + payload_len];
    memcpy(packet, &ip, sizeof(iphdr));
    memcpy(packet + sizeof(iphdr), &tcp, sizeof(tcphdr));
    memcpy(packet + sizeof(iphdr) + sizeof(tcphdr), payload, payload_len);

    // --- Send Packet ---
    struct sockaddr_in dest;
    memset(&dest, 0, sizeof(dest));
    dest.sin_family = AF_INET;
    dest.sin_addr.s_addr = ip.daddr;

    if (sendto(sock, packet, sizeof(packet), 0, 
              reinterpret_cast<sockaddr*>(&dest), sizeof(dest)) < 0) {
        throw std::runtime_error(std::string("sendto failed: ") + strerror(errno));
    }

    std::cout << "[+] Spoofed packet sent to " << inet_ntoa(dest.sin_addr) << std::endl;
    close(sock);
    return 0;
}

Key Code Enhancements

IP Checksum Calculation
- Unlike the original code, this version manually computes the IP header checksum. The kernel does not do this when IPPROTO_RAW is used.
Error Handling
- Uses C++ exceptions for clarity and leverages strerror(errno) for actionable diagnostics.
Memory Safety
- Explicit buffer management with bounds checking
Standards Compliance
- Adheres to RFC 793 (TCP) and RFC 791 (IP) for header field configurations.

Mitigations Against Spoofing

Ingress/Egress Filtering: Block packets with invalid source IPs at network boundaries.
Cryptographic Authentication: Protocols like TLS (transport layer) and IPsec (network layer).
Anomaly Detection: Machine learning models to flag abnormal traffic patterns.

Conclusion

IP spoofing is a testament to the adage, “Know thy enemy.” While this article equips you with the technical knowledge to craft spoofed packets, its value lies in fostering defense-first thinking. Use this code only in environments where you have explicit authorization, and prioritize contributing to the defensive tools and policies that keep networks secure.

This code will work only in local network don't expect it will go beyond firewall, new isp system now rewrite your packet and reset your IP headers.

creating your own Docker like what a shiny title and hard work A year ago, I built a minimal container in Go. Now, it's time for a revisit! This time, I'm tackling network isolation, resource limits, and deeper container architecture.

mohamed alaaeldin — Fri, 21 Feb 2025 01:25:52 +0000

Beyond Basics: Building a More Powerful Container in Go — Network Isolation & Advanced Features

mohamed alaaeldin ・ Feb 21

#programming #devops #go #containers

Beyond Basics: Building a More Powerful Container in Go — Network Isolation & Advanced Features

mohamed alaaeldin — Fri, 21 Feb 2025 01:21:41 +0000

Containers Uncovered: More Than Just Lightweight Virtual Machines!”

If you’re like me — always wondering how things work and eager to build them with your own mind and hands — you’re in the right place!
In the first part of this article (Part 1), I attempted to build a minimal container system using only Go, relying on Linux’s unshare and namespaces. It was purely a demonstration, and I wasn’t aiming to develop a fully functional container runtime tool. I intentionally left out many critical aspects, such as security, networking, and image management.
I initially thought it would be simple, but I quickly realized that even a basic container system involves thousands of concepts and implementations. However, my passion for understanding and building things kept me going.
Now, after a year since my first article on Building a Minimal Container in Go, I’ve realized that both my code and my original article need a fresh perspective. So, it’s time for a revisit!

System Architect

Core Components

User CLI

Responsibilities:
Parse user commands (run, exec, ps, rm)
Communicate with daemon via RPC or any other way
Format and display output

Key Features:

Command completion
Output formatting (JSON/YAML)
Log streaming

Container Daemon

Responsibilities:

Manage container lifecycle
Maintain container state database
Coordinate between components

Key Features:

REST/gRPC API
Event logging
Resource tracking

Container Runtime

Components:

Namespace Manager: CLONE_NEW* flags handling and more flags in real world .
Cgroups Manager: Resource constraints
Filesystem Setup: RootFS preparation

Features:

OCI runtime spec compliance
User namespace remapping
Seccomp/AppArmor profiles

Image Service

Components:

Registry Client: Docker Hub integration or you own images services if you will go wiled
Layer Manager: OverlayFS/BTRFS
Snapshotter: Copy-on-write layers

Features:

Image caching
Signature verification
Garbage collection

Network Manager

Components:

CNI Plugins: Bridge, MACVLAN, IPVLAN
IPAM: DHCP/Static allocation
Service Mesh: DNS, service discovery

Features:

Multi-host networking
Network policies
Port mapping

Storage Driver

Components:

Volume Manager: Bind mounts
Snapshot Manager: Incremental backups
Quota Enforcer: Disk limits

Features:

Persistent storage
Temporary filesystems
Encryption support

this schema will give you a bigger picture


                           +---------------------+
                           |      User CLI       |
                           | (run, exec, ps, rm) |
                           +----------+----------+
                                      |
                                      | (gRPC/HTTP)
                                      v
                           +---------------------+
                           |   Container Daemon  |
                           | (State Management)  |
                           +----------+----------+
                                      |
                   +------------------+------------------+
                   |                  |                  |
         +----------+----------+ +-----+--------+ +-------+---------+
         |   Container Runtime | | Image Service| | Network Manager |
         | (namespace/cgroups) | | (OCI Images)  | | (CNI Plugins)   |
         +----------+----------+ +-----+--------+ +-------+---------+
                   |                  |                  |
         +---------v---------+ +------v-------+ +--------v---------+
         | Linux Kernel       | | Storage Driver| | Host Networking |
         | - namespaces       | | (OverlayFS)   | | (iptables/bridge)|
         | - cgroups v2       | +---------------+ +------------------+
         | - capabilities     |
         +--------------------+

It has been a long journey for me to learn and think through every component. I encountered many challenges, especially with aspects like OverlayFS and networking.

My biggest issue in my first implementation was networking. It was really difficult to isolate the child container and set up its own bridged network.

To solve network isolation, you need to think clearly 🤔 at this stage.

First, you need to create a bridge on the host with two virtual interfaces:

The first interface remains on the host.
The second interface is moved to the child container 🫙.

The real challenge here is managing command signaling between the host and the child container.

In my approach, I will attempt to create a proof of concept implementation.
Understanding Container Networking

When we create containers, one of the most crucial aspects is network isolation. Think of it like giving each container its own private network environment, complete with its own network interfaces, IP addresses, and routing rules. Let’s break down how we achieve this in our container implementation.
The Network Setup Process

Creating the Network Namespace

First, we create a separate network namespace for our container. This is like giving the container its own private networking room:

const ContainerName = "mycontainer"

func createNetworkNamespace(name string) error {
    // Create directory for network namespaces
    if err := os.MkdirAll("/var/run/netns", 0755); err != nil {
        return err
    }

    // Create the namespace file
    nsFile := filepath.Join("/var/run/netns", name)
    fd, err := os.Create(nsFile)
    if err != nil {
        return err
    }
    fd.Close()

    // Bind mount it to make it accessible
    return syscall.Mount("/proc/self/ns/net", nsFile, "bind", syscall.MS_BIND, "")
}

Setting Up Virtual Network Interfaces

We create a virtual network cable (veth pair) to connect our container to the host system:

const (
    VethHost      = "veth0"  // Host end of the cable
    VethContainer = "veth1"  // Container end of the cable
    ContainerIP   = "10.0.0.2/24"
    HostIP        = "10.0.0.1/24"
    Gateway       = "10.0.0.1"
)

The setup happens in two parts:
1-On the host side:

func setupHostNetwork(pid int) error {
    // Create the virtual network cable (veth pair)
    if err := exec.Command("ip", "link", "add", VethHost, "type", "veth", 
        "peer", "name", VethContainer).Run(); err != nil {
        return fmt.Errorf("failed to create veth pair: %v", err)
    }

    // Move one end to the container
    if err := exec.Command("ip", "link", "set", VethContainer, 
        "netns", fmt.Sprintf("%d", pid)).Run(); err != nil {
        return fmt.Errorf("failed to move veth to container: %v", err)
    }

    // Configure the host end
    if err := exec.Command("ip", "link", "set", VethHost, "up").Run(); err != nil {
        return fmt.Errorf("failed to bring up host interface: %v", err)
    }
    if err := exec.Command("ip", "addr", "add", HostIP, "dev", VethHost).Run(); err != nil {
        return fmt.Errorf("failed to assign IP to host interface: %v", err)
    }
}

2 — Inside the container:

func setupContainerNetwork() error {
    // Enable the loopback interface
    if err := exec.Command("ip", "link", "set", "lo", "up").Run(); err != nil {
        return fmt.Errorf("failed to bring up lo: %v", err)
    }

    // Configure the container's network interface
    if err := exec.Command("ip", "link", "set", VethContainer, "up").Run(); err != nil {
        return fmt.Errorf("failed to bring up veth: %v", err)
    }
    if err := exec.Command("ip", "addr", "add", ContainerIP, 
        "dev", VethContainer).Run(); err != nil {
        return fmt.Errorf("failed to assign IP to veth: %v", err)
    }
    if err := exec.Command("ip", "route", "add", "default", 
        "via", Gateway).Run(); err != nil {
        return fmt.Errorf("failed to add default route: %v", err)
    }
}

Internet Connectivity

To allow our container to access the internet, we need to set up NAT (Network Address Translation) rules. This is like setting up a router for our container:

func setupHostNetwork(pid int) error {
    // Get the host's internet-connected interface
    iface, err := getDefaultInterface()
    if err != nil {
        return fmt.Errorf("failed to get default interface: %v", err)
    }

    // Set up NAT and forwarding rules
    cmds := [][]string{
        {"sysctl", "-w", "net.ipv4.ip_forward=1"},
        {"iptables", "-t", "nat", "-A", "POSTROUTING", 
            "-s", "10.0.0.0/24", "-o", iface, "-j", "MASQUERADE"},
        {"iptables", "-A", "FORWARD", "-i", iface, 
            "-o", VethHost, "-j", "ACCEPT"},
        {"iptables", "-A", "FORWARD", "-i", VethHost, 
            "-o", iface, "-j", "ACCEPT"},
    }

    for _, cmd := range cmds {
        if out, err := exec.Command(cmd[0], cmd[1:]...).CombinedOutput(); err != nil {
            return fmt.Errorf("failed %v: %s\n%s", cmd, err, out)
        }
    }
}

finally , Resource Cleanup

One often overlooked but crucial aspect is cleaning up network resources when the container stops. Our implementation handles this through a ResourceManager:


type ResourceManager struct {
    containerName string
    vethHost      string
    mounts        []string
    namespaces    []string
}

func (rm *ResourceManager) cleanupNetwork() error {
    // Clean up iptables rules
    if err := rm.cleanupIptablesRules(); err != nil {
        log.Printf("Warning: iptables cleanup failed: %v", err)
    }

    // Remove the virtual network interface
    if out, err := exec.Command("ip", "link", "delete", 
        rm.vethHost).CombinedOutput(); err != nil {
        log.Printf("Warning: failed to delete veth interface: %v (%s)", err, out)
    }

    return nil
}

How It All Works Together

When starting a container:

Create a new network namespace
Create virtual network interfaces (veth pair)
Configure IP addresses and routing
Set up NAT for internet access
Mount necessary filesystems and set up devices

2 .During container runtime:

Container uses its virtual network interface for all network communication
Outgoing traffic goes through NAT to reach the internet
Incoming traffic is routed back to the container

3 . When stopping a container:

Clean up iptables rules
Remove virtual interfaces
Unmount network namespace
Remove namespace files

Common Issues and Debugging

When implementing container networking, you might encounter these common issues:

DNS Resolution Problems

Our implementation includes DNS setup:

// in most cases this will case error , still trying to solve it 
func setupDNS() error {
    resolvHost := "/etc/resolv.conf"
    resolvContainer := filepath.Join(RootFS, "etc/resolv.conf")
    return syscall.Mount(resolvHost, resolvContainer, "bind", 
        syscall.MS_BIND|syscall.MS_RDONLY, "")
}

2.Network Interface Issues

Always check interface status with ip link show
Verify IP assignments with ip addr show
Check routing with ip route show

3.Connection Problems

Verify iptables rules are correctly set
Check IP forwarding is enabled
Ensure the host interface is up and working

Security Considerations

Our implementation includes several security features:

Network Isolation

Each container gets its own network namespace
Network traffic is isolated between containers

2.Resource Cleanup

Proper cleanup of network resources prevents resource leaks
Automatic cleanup on container exit

This networking implementation provides a solid foundation for container isolation while maintaining internet connectivity. While it’s simpler than production container runtimes, it demonstrates the core concepts of container networking.

this was the hard part for me and i have tryed so many implemention to achive that . you have to keep in main what and where your command executted . some times you find your self trying to create vath’s in continer or you cannot connect or move the continer interface from host to chiled

you have to read my previeus articl to know what we are doing i had clean up my code and add every thing agine to test network isolation

do not forget to change RootFS to your root fs like “ubuntu or whatever image you will run”

package main

import (
 "fmt"
 "log"
 "os"
 "os/exec"
 "path/filepath"
 "strings"
 "syscall"
 "os/signal" 
)

const (
 ContainerName = "mycontainer"
 VethHost      = "veth0"
 VethContainer = "veth1"
 ContainerIP   = "10.0.0.2/24"
 HostIP        = "10.0.0.1/24"
 Gateway       = "10.0.0.1"
 RootFS        = "/mnt/drive/go-projects/lc-images-regs/ubuntu_fs"
)



type ResourceManager struct {
    containerName string
    vethHost      string
    mounts        []string
    namespaces    []string
}
func NewResourceManager(containerName string) *ResourceManager {
    return &ResourceManager{
        containerName: containerName,
        vethHost:     VethHost,
        mounts: []string{
            "/proc",
            "/dev/pts",
            "/dev",
        },
        namespaces: []string{
            "net",
            "uts",
            "pid",
            "ipc",
        },
    }
}

func (rm *ResourceManager) Setup() {
    // Set up signal handling
    sigChan := make(chan os.Signal, 1)
    signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)

    go func() {
        sig := <-sigChan
        log.Printf("Received signal %v, cleaning up...", sig)
        rm.Cleanup()
        os.Exit(1)
    }()
}

func (rm *ResourceManager) Cleanup() error {
    var errors []string

    // 1. Clean up network resources
    if err := rm.cleanupNetwork(); err != nil {
        errors = append(errors, fmt.Sprintf("network cleanup error: %v", err))
    }

    // 2. Clean up mounts
    if err := rm.cleanupMounts(); err != nil {
        errors = append(errors, fmt.Sprintf("mount cleanup error: %v", err))
    }

    // 3. Clean up namespaces
    if err := rm.cleanupNamespaces(); err != nil {
        errors = append(errors, fmt.Sprintf("namespace cleanup error: %v", err))
    }

    if len(errors) > 0 {
        return fmt.Errorf("cleanup errors: %s", strings.Join(errors, "; "))
    }
    return nil
}

func (rm *ResourceManager) cleanupNetwork() error {
    // Clean up iptables rules first
    if err := rm.cleanupIptablesRules(); err != nil {
        log.Printf("Warning: iptables cleanup failed: %v", err)
    }

    // Clean up veth interfaces
    if out, err := exec.Command("ip", "link", "delete", rm.vethHost).CombinedOutput(); err != nil {
        log.Printf("Warning: failed to delete veth interface: %v (%s)", err, out)
    }

    return nil
}

func (rm *ResourceManager) cleanupIptablesRules() error {
    iface, err := getDefaultInterface()
    if err != nil {
        return fmt.Errorf("failed to get default interface: %v", err)
    }

    rules := [][]string{
        {"iptables", "-D", "FORWARD", "-i", iface, "-o", rm.vethHost, "-j", "ACCEPT"},
        {"iptables", "-D", "FORWARD", "-i", rm.vethHost, "-o", iface, "-j", "ACCEPT"},
        {"iptables", "-t", "nat", "-D", "POSTROUTING", "-s", "10.0.0.0/24", "-o", iface, "-j", "MASQUERADE"},
    }

    for _, rule := range rules {
        if out, err := exec.Command(rule[0], rule[1:]...).CombinedOutput(); err != nil {
            log.Printf("Warning: failed to remove iptables rule: %v (%s)", err, out)
        }
    }

    return nil
}

func (rm *ResourceManager) cleanupMounts() error {
    for _, mount := range rm.mounts {
        mountPath := filepath.Join(RootFS, mount)
        if err := syscall.Unmount(mountPath, syscall.MNT_DETACH); err != nil {
            log.Printf("Warning: failed to unmount %s: %v", mountPath, err)
        }
    }
    return nil
}

func (rm *ResourceManager) cleanupNamespaces() error {
    for _, ns := range rm.namespaces {
        nsPath := filepath.Join("/var/run/netns", rm.containerName)
        if err := syscall.Unmount(nsPath, syscall.MNT_DETACH); err != nil {
            log.Printf("Warning: failed to unmount namespace %s: %v", ns, err)
        }
        if err := os.Remove(nsPath); err != nil {
            log.Printf("Warning: failed to remove namespace file %s: %v", nsPath, err)
        }
    }
    return nil
}

func cleanupExistingResources() error {
 // Cleanup network namespace
 if _, err := os.Stat("/var/run/netns/" + ContainerName); err == nil {
  if err := cleanupNetworkNamespace(ContainerName); err != nil {
   return fmt.Errorf("failed to cleanup existing network namespace: %v", err)
  }
 }

 // Cleanup veth interfaces
 if _, err := exec.Command("ip", "link", "show", VethHost).CombinedOutput(); err == nil {
  if err := exec.Command("ip", "link", "delete", VethHost).Run(); err != nil {
   return fmt.Errorf("failed to delete existing veth interface: %v", err)
  }
 }

 // Cleanup iptables rules
 if err := cleanupIptablesRules(); err != nil {
  return fmt.Errorf("failed to cleanup iptables rules: %v", err)
 }

 return nil
}

func cleanupIptablesRules() error {
 iface, err := getDefaultInterface()
 if err != nil {
  return fmt.Errorf("failed to get default interface: %v", err)
 }

 cmds := [][]string{
  {"iptables", "-D", "FORWARD", "-i", iface, "-o", VethHost, "-j", "ACCEPT"},
  {"iptables", "-D", "FORWARD", "-i", VethHost, "-o", iface, "-j", "ACCEPT"},
  {"iptables", "-t", "nat", "-D", "POSTROUTING", "-s", "10.0.0.0/24", "-o", iface, "-j", "MASQUERADE"},
 }

 for _, cmd := range cmds {
  // Ignore errors since rules might not exist
  exec.Command(cmd[0], cmd[1:]...).Run()
 }

 return nil
}
func getDefaultInterface() (string, error) {
 out, err := exec.Command("ip", "route", "show", "default").CombinedOutput()
 if err != nil {
  return "", err
 }

 fields := strings.Fields(string(out))
 for i, field := range fields {
  if field == "dev" && i+1 < len(fields) {
   return fields[i+1], nil
  }
 }

 return "", fmt.Errorf("no default interface found")
}

func main() {
 if len(os.Args) < 2 {
  log.Fatal("Usage: [run|child] command [args...]")
 }

 switch os.Args[1] {
 case "run":
  run()
 case "child":
  child()
 default:
  log.Fatalf("unknown command: %s", os.Args[1])
 }
}
func setupCgroups(ContainerName string , pid int, cpuShares, memoryLimitMB int) error {
    cgroupBase := "/sys/fs/cgroup"
    containerID := ContainerName // fmt.Sprintf("container_%d", pid)

    // Create CPU cgroup
    cpuPath := filepath.Join(cgroupBase, "cpu", containerID)
    os.MkdirAll(cpuPath, 0755)
    os.WriteFile(filepath.Join(cpuPath, "cpu.shares"), []byte(fmt.Sprintf("%d", cpuShares)), 0644)
    os.WriteFile(filepath.Join(cpuPath, "tasks"), []byte(fmt.Sprintf("%d", pid)), 0644)

    // Create memory cgroup
    memoryPath := filepath.Join(cgroupBase, "memory", containerID)
    os.MkdirAll(memoryPath, 0755)
    os.WriteFile(filepath.Join(memoryPath, "memory.limit_in_bytes"), []byte(fmt.Sprintf("%d", memoryLimitMB*1024*1024)), 0644)
    os.WriteFile(filepath.Join(memoryPath, "tasks"), []byte(fmt.Sprintf("%d", pid)), 0644)


 uidMap := fmt.Sprintf("0 %d 1", os.Getuid())
 gidMap := fmt.Sprintf("0 %d 1", os.Getgid())

 os.WriteFile(fmt.Sprintf("/proc/%d/uid_map", pid), []byte(uidMap), 0644)
 os.WriteFile(fmt.Sprintf("/proc/%d/gid_map", pid), []byte(gidMap), 0644)
    return nil
}
func run() {
 rm := NewResourceManager(ContainerName)
    rm.Setup()
    defer rm.Cleanup()

 if err := cleanupExistingResources(); err != nil {
  log.Printf("Cleanup warning: %v", err)
 }

 // Create network namespace
 if err := createNetworkNamespace(ContainerName); err != nil {
  log.Fatalf("Failed to create network namespace: %v", err)
 }

 // Start container process
 cmd := exec.Command("/proc/self/exe", append([]string{"child"}, os.Args[2:]...)...)
 cmd.Stdin = os.Stdin
 cmd.Stdout = os.Stdout
 cmd.Stderr = os.Stderr
 cmd.SysProcAttr = &syscall.SysProcAttr{
  Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS | syscall.CLONE_NEWNET |

  syscall.CLONE_NEWIPC ,


 }

 if err := cmd.Start(); err != nil {
  log.Fatalf("Failed to start container: %v", err)
 }
 pid := cmd.Process.Pid
 if err :=setupCgroups(ContainerName , pid , 512 , 256  ); err != nil { // Example: 512 CPU shares, 256 MB memory limit
  log.Fatalf("Failed to setup cgroups: %v", err)
 }
 // Configure host-side networking
 if err := setupHostNetwork(cmd.Process.Pid); err != nil {
  log.Fatalf("Failed to setup host network: %v", err)
 }

 // Wait for container to exit
 if err := cmd.Wait(); err != nil {
  log.Fatalf("Container failed: %v", err)
 }

 // Cleanup
 if err := cleanupNetworkNamespace(ContainerName); err != nil {
  log.Printf("Failed to cleanup network namespace: %v", err)
 }
}

func child() {
 // Setup container environment
 if err := setupContainer(); err != nil {
  log.Fatalf("Failed to setup container: %v", err)
 }

 // Execute command
 if len(os.Args) < 3 {
  log.Fatal("No command specified")
 }
 cmd := exec.Command(os.Args[2], os.Args[3:]...)
 cmd.Stdin = os.Stdin
 cmd.Stdout = os.Stdout
 cmd.Stderr = os.Stderr
 if err := cmd.Run(); err != nil {
  log.Fatalf("Command failed: %v", err)
 }
}

func createNetworkNamespace(name string) error {
 // Create bind mount for ip netns compatibility
 if err := os.MkdirAll("/var/run/netns", 0755); err != nil {
  return err
 }

 // Create namespace file
 nsFile := filepath.Join("/var/run/netns", name)
 fd, err := os.Create(nsFile)
 if err != nil {
  return err
 }
 fd.Close()

 // Bind mount
 return syscall.Mount("/proc/self/ns/net", nsFile, "bind", syscall.MS_BIND, "")
}

func cleanupNetworkNamespace(name string) error {
 nsFile := filepath.Join("/var/run/netns", name)
 if err := syscall.Unmount(nsFile, 0); err != nil {
  return fmt.Errorf("failed to unmount network namespace: %v", err)
 }
 // Remove the file to complete cleanup.
 if err := os.Remove(nsFile); err != nil {
  return fmt.Errorf("failed to remove namespace file %s: %v", nsFile, err)
 }
 return nil
}


func setupHostNetwork(pid int) error {
 // Get host's default interface
 iface, err := getDefaultInterface()
 if err != nil {
  return fmt.Errorf("failed to get default interface: %v", err)
 }

 // Create veth pair
 if err := exec.Command("ip", "link", "add", VethHost, "type", "veth", "peer", "name", VethContainer).Run(); err != nil {
  return fmt.Errorf("failed to create veth pair: %v", err)
 }

 // Move container end to namespace
 if err := exec.Command("ip", "link", "set", VethContainer, "netns", fmt.Sprintf("%d", pid)).Run(); err != nil {
  return fmt.Errorf("failed to move veth to container: %v", err)
 }

 // Configure host interface
 if err := exec.Command("ip", "link", "set", VethHost, "up").Run(); err != nil {
  return fmt.Errorf("failed to bring up host interface: %v", err)
 }
 if err := exec.Command("ip", "addr", "add", HostIP, "dev", VethHost).Run(); err != nil {
  return fmt.Errorf("failed to assign IP to host interface: %v", err)
 }

 cmds := [][]string{

  {"sysctl", "-w", "net.ipv4.ip_forward=1"},
  {"iptables", "-t", "nat", "-A", "POSTROUTING", "-s", "10.0.0.0/24", "-o", iface, "-j", "MASQUERADE"},
  {"iptables", "-A", "FORWARD", "-i", iface, "-o", VethHost, "-j", "ACCEPT"},
  {"iptables", "-A", "FORWARD", "-i", VethHost, "-o", iface, "-j", "ACCEPT"},
 }

 for _, cmd := range cmds {
  if out, err := exec.Command(cmd[0], cmd[1:]...).CombinedOutput(); err != nil {
   return fmt.Errorf("failed %v: %s\n%s", cmd, err, out)
  }
 }

 return nil
}

func setupContainer() error {
 // Setup root filesystem
 if err := syscall.Chroot(RootFS); err != nil {
  return fmt.Errorf("chroot failed: %v", err)
 }
 if err := os.Chdir("/"); err != nil {
  return fmt.Errorf("chdir failed: %v", err)
 }

 // Mount proc
 if err := syscall.Mount("proc", "/proc", "proc", 0, ""); err != nil {
  return fmt.Errorf("failed to mount proc: %v", err)
 }

 // Setup devices
 if err := setupDevices(); err != nil {
  return fmt.Errorf("failed to setup devices: %v", err)
 }

 // Configure network
 if err := setupContainerNetwork(); err != nil {
  return fmt.Errorf("failed to setup network: %v", err)
 }

 //if err := setupDNS(); err != nil {
 // return fmt.Errorf("DNS setup failed: %v", err)
 //}

 return nil
}

func setupDNS() error {
 // Copy host's resolv.conf
 resolvHost := "/etc/resolv.conf"
 resolvContainer := filepath.Join(RootFS, "etc/resolv.conf")

 // Create container's /etc if missing
 if err := os.MkdirAll(filepath.Join(RootFS, "etc"), 0755); err != nil {
  return err
 }

 // Bind mount host's resolv.conf
 return syscall.Mount(resolvHost, resolvContainer, "bind", syscall.MS_BIND|syscall.MS_RDONLY, "")
}

func setupDevices() error {
 // Mount tmpfs for /dev
 if err := syscall.Mount("tmpfs", "/dev", "tmpfs", 0, "size=64k,mode=755"); err != nil {
  return err
 }

 // Create /dev/pts directory if missing
 devPts := "/dev/pts"
 if err := os.MkdirAll(devPts, 0755); err != nil {
  return fmt.Errorf("mkdir %s failed: %v", devPts, err)
 }

 // Mount devpts on /dev/pts for pty support
 if err := syscall.Mount("devpts", devPts, "devpts", 0, "mode=0620,ptmxmode=0666"); err != nil {
  return fmt.Errorf("failed to mount devpts on %s: %v", devPts, err)
 }
 // Create basic devices
 devices := []struct {
  name  string
  major uint32
  minor uint32
 }{
  {"null", 1, 3},
  {"zero", 1, 5},
  {"random", 1, 8},
  {"urandom", 1, 9},
 }

 for _, dev := range devices {
  path := filepath.Join("/dev", dev.name)
  if err := syscall.Mknod(path, syscall.S_IFCHR|0666, int(makedev(dev.major, dev.minor))); err != nil {
   return err
  }
 }

 return nil
}

func makedev(major, minor uint32) uint64 {
 return (uint64(major) << 8) | uint64(minor)
}

func setupContainerNetwork() error {
 // Bring up loopback
 if err := exec.Command("ip", "link", "set", "lo", "up").Run(); err != nil {
  return fmt.Errorf("failed to bring up lo: %v", err)
 }

 // Configure veth interface
 if err := exec.Command("ip", "link", "set", VethContainer, "up").Run(); err != nil {
  return fmt.Errorf("failed to bring up veth: %v", err)
 }
 if err := exec.Command("ip", "addr", "add", ContainerIP, "dev", VethContainer).Run(); err != nil {
  return fmt.Errorf("failed to assign IP to veth: %v", err)
 }
 if err := exec.Command("ip", "route", "add", "default", "via", Gateway).Run(); err != nil {
  return fmt.Errorf("failed to add default route: %v", err)
 }

 return nil
}

Important point: You must mount and create essential virtual devices and establish communication (such as pipes or signals) between the host and child container .

func setupDevices() error {
 // Mount tmpfs for /dev
 if err := syscall.Mount("tmpfs", "/dev", "tmpfs", 0, "size=64k,mode=755"); err != nil {
  return err
 }

 // Create /dev/pts directory if missing
 devPts := "/dev/pts"
 if err := os.MkdirAll(devPts, 0755); err != nil {
  return fmt.Errorf("mkdir %s failed: %v", devPts, err)
 }

 // Mount devpts on /dev/pts for pty support
 if err := syscall.Mount("devpts", devPts, "devpts", 0, "mode=0620,ptmxmode=0666"); err != nil {
  return fmt.Errorf("failed to mount devpts on %s: %v", devPts, err)
 }
 // Create basic devices
 devices := []struct {
  name  string
  major uint32
  minor uint32
 }{
  {"null", 1, 3},
  {"zero", 1, 5},
  {"random", 1, 8},
  {"urandom", 1, 9},
 }

 for _, dev := range devices {
  path := filepath.Join("/dev", dev.name)
  if err := syscall.Mknod(path, syscall.S_IFCHR|0666, int(makedev(dev.major, dev.minor))); err != nil {
   return err
  }
 }

 return nil
}

func NewResourceManager(containerName string) *ResourceManager {
    return &ResourceManager{
        containerName: containerName,
        vethHost:     VethHost,
        mounts: []string{
            "/proc",
            "/dev/pts",
            "/dev",
        },
        namespaces: []string{
            "net",
            "uts",
            "pid",
            "ipc",
        },
    }
}

func (rm *ResourceManager) Setup() {
    // Set up signal handling
    sigChan := make(chan os.Signal, 1)
    signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)

    go func() {
        sig := <-sigChan
        log.Printf("Received signal %v, cleaning up...", sig)
        rm.Cleanup()
        os.Exit(1)
    }()
}

Now you have a broad overview, but you still have a long journey ahead to achieve what production-ready container runtime systems offer.

If you need system file images to test your code, you can use Docker to download one.

$ docker run -d --rm --name ubuntu_fs ubuntu:20.04 sleep 1000
$ mkdir -p ./ubuntu_fs
$ docker cp ubuntu_fs:/ ./ubuntu_fs
$ docker stop ubuntu_fs

Or use tool like debootstrap

sudo apt-get update
sudo apt-get install debootstrap
sudo mkdir -p /path/to/rootfs
sudo debootstrap stable /path/to/rootfs http://deb.debian.org/debian

Sometimes, while testing, you may need to install software in your container image from the host if your child container struggles to access the internet.

sudo chroot /path/to/rootfs /bin/sh -c "apk add --no-cache iproute2"

or in ubuntu_fs

sudo chroot /mnt/drive/go-projects/lc-images-regs/ubuntu_fs /bin/sh -c "apt-get update && apt-get install -y iproute2"

Note: Sometimes, when you try to start the container by running the following command to start Bash as the entry point, you may encounter a bug:

sudo go run Main.go run sudo /bin/bash

you will face this bug

2025/02/21 00:26:28 Failed to setup container: failed to setup network: failed to bring up veth: exit status 1
2025/02/21 01:26:28 Failed to setup host network: failed to assign IP to host interface: exit status 1
exit status 1

This happens due to resource cleanup errors. You can either ignore it and retry the command up to three times or fix the issue.

You still need to implement DNS to align with the original system design. What we built is just a proof of concept application.

My next step is to ensure resource limitations and create an image composer like Docker while utilizing OverlayFS. Until then, if you need any help, feel free to DM me.

this is discord channel for this topic only join me :

https://discord.gg/GX4JuVtD

Happy coding, everybody!

Creating a Minimal Container in Go: A Step-by-Step Guide ( part 1 )

mohamed alaaeldin — Fri, 21 Feb 2025 01:08:37 +0000

What is Containers any way!
Containers are lightweight, portable, and efficient, making them a popular choice for deploying and running applications. In this tutorial, we’ll guide you through the process of creating a minimal container using Go. The example code provided focuses on essential containerization concepts, including namespaces, chroot, and control groups (cgroups).

Before getting started, ensure you have the following installed:

Go programming language: Install Go
Basic understanding of Linux namespaces and control groups

introduction
So what is Linux namespaces and control groups ?

Namespaces have been part of the Linux kernel since about 2002, and over time more tooling and namespace types have been added. Real container support was added to the Linux kernel only in 2013, however. This is what made namespaces really useful and brought them to the masses.

But what are namespaces exactly? Here’s a wordy definition from Wikipedia:

“Namespaces are a feature of the Linux kernel that partitions kernel resources such that one set of processes sees one set of resources while another set of processes sees a different set of resources.”

In other words, the key feature of namespaces is that they isolate processes from each other. On a server where you are running many different services, isolating each service and its associated processes from other services means that there is a smaller blast radius for changes, as well as a smaller footprint for security‑related concerns. Mostly though, isolating services meets the architectural style of microservices as described by Martin Fowler.
Types of Namespaces

Within the Linux kernel, there are different types of namespaces. Each namespace has its own unique properties:

A user namespace has its own set of user IDs and group IDs for assignment to processes. In particular, this means that a process can have root privilege within its user namespace without having it in other user namespaces.
A process ID (PID) namespace assigns a set of PIDs to processes that are independent from the set of PIDs in other namespaces. The first process created in a new namespace has PID 1 and child processes are assigned subsequent PIDs. If a child process is created with its own PID namespace, it has PID 1 in that namespace as well as its PID in the parent process’ namespace. See below for an example.
A network namespace has an independent network stack: its own private routing table, set of IP addresses, socket listing, connection tracking table, firewall, and other network‑related resources.
A mount namespace has an independent list of mount points seen by the processes in the namespace. This means that you can mount and unmount filesystems in a mount namespace without affecting the host filesystem.
An interprocess communication (IPC) namespace has its own IPC resources, for example POSIX message queues.
A UNIX Time‑Sharing (UTS) namespace allows a single system to appear to have different host and domain names to different processes.

the container are fast isolated environment , we will focus on this part many things are involved and my main goal is to Demystifying Containers

assuming that you are on a linux machine (try Power shell Ubuntu image if you are on Windows :-)

run this command : id

host-machine $ id

uid=1000(mohamed) gid=1000(mohamed) groups=1000(mohamed) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c.1023

unshare command

Now I run the following unshare command to create a new namespace with its own user and PID namespaces. I map the root user to the new namespace (in other words, I have root privilege within the new namespace), mount a new proc filesystem, and fork my process (in this case, bash) in the newly created namespace.

unshare --user --pid --map-root-user --mount-proc --fork bash

Congratulation , you are in isolated name space and some how you are on
isolated PID in same file system and same network , your entry point /bin/bash

The ps -ef command shows there are two processes running – bash and the ps command itself – and the id command confirms that I’m root in the new namespace (which is also indicated by the changed command prompt):

root # ps -ef
UID         PID     PPID  C STIME TTY        TIME CMD
root          1        0  0 14:46 pts/0  00:00:00 bash
root         15        1  0 14:46 pts/0  00:00:00 ps -ef
root # id
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c.1023

Namespaces and Containers

Namespaces are one of the technologies that containers are built on, used to enforce segregation of resources. We’ve shown how to create namespaces manually, but container runtimes like Docker, rkt, podman , runC , containerD , and many other container technology
one of most unique projects are https://katacontainers.io/ they claim that they are mix between container and VM’s .
What Are cgroups?

cgroups, or control groups, are a Linux kernel feature that enables the management and limitation of system resources like CPU, memory, and network bandwidth, among others. We can use cgroups to set limits on these resources and distribute them among different groups of processes.

cgroups have a hierarchical structure with root and child, each with resource limits set by controllers — for example, a CPU controller for CPU time or a memory controller for memory.

We can use cgroups for various purposes, such as controlling resource usage in a multi-tenant environment, providing Quality of Service (QoS) guarantees, and running containers.

Cgroups provide the following features:

Resource limits — You can configure a cgroup to limit how much of a particular resource (memory or CPU, for example) a process can use.
Prioritization — You can control how much of a resource (CPU, disk, or network) a process can use compared to processes in another cgroup when there is resource contention.
Accounting — Resource limits are monitored and reported at the cgroup level.
Control — You can change the status (frozen, stopped, or restarted) of all processes in a cgroup with a single command.

Creating a cgroup

The following command creates a v1 cgroup (you can tell by pathname format) called foo and sets the memory limit for it to 50,000,000 bytes (50 MB).

root # mkdir -p /sys/fs/cgroup/memory/foo
root # echo 50000000 > /sys/fs/cgroup/memory/foo/memory.limit_in_bytes

Now I can assign a process to the cgroup, thus imposing the cgroup’s memory limit on it. I’ve written a shell script called test.sh, which prints cgroup testing tool to the screen, and then waits doing nothing. For my purposes, it is a process that continues to run until I stop it.

I start test.sh in the background and its PID is reported as 2428. The script produces its output and then I assign the process to the cgroup by piping its PID into the cgroup file /sys/fs/cgroup/memory/foo/cgroup.procs.

root # ./test.sh &
[1] 2428
root # cgroup testing tool
root # echo 2428 > /sys/fs/cgroup/memory/foo/cgroup.procs

To validate that my process is in fact subject to the memory limits that I defined for cgroup foo, I run the following ps command. The -o cgroup flag displays the cgroups to which the specified process (2428) belongs. The output confirms that its memory cgroup is foo.

root # ps -o cgroup 2428
CGROUP
12:pids:/user.slice/user-0.slice/\
session-13.scope,10:devices:/user.slice,6:memory:/foo,...

By default, the operating system terminates a process when it exceeds a resource limit defined by its cgroup.

and this fair amount of information about namespace and cgroup
you can read full doc about it by Scott van Kalken of F5
at this link , also this post Demystifying Containers 101 and this one focus on Docker ecosystem “A Beginner-Friendly Introduction to Containers, VMs and Docker”
part 1 : Chroot
i will not use Namespaces , “at this part”

this may surprise however i will achieve the isolation , we will use Chroot a simple UNIX tool

chroot, short for "change root," is a Unix system call that changes the root directory of a process to a specified path, effectively creating a new root filesystem for the process and its children. This can be a powerful tool for creating isolated environments or "chroot jails."
How Chroot Works:

Setting a New Root Directory: When you execute the chroot system call or the chroot command in the shell, it changes the root directory for the process and its children. The new root directory becomes the / (root) directory for that process, isolating it from the actual root directory of the host system.
Isolation: After the chroot operation, the process and its children can only access files and directories within the new root directory. They cannot access files outside this new root, providing a level of isolation and containment.

Use Cases:

System Recovery: chroot is commonly used in system recovery scenarios. If your system becomes unbootable or experiences issues, you can boot from a live CD/USB, chroot into the broken system, and make necessary repairs without affecting the rest of the host system.
Environment Isolation: Developers and system administrators may use chroot to create isolated environments for testing or building software. This is especially common in scenarios where different versions of libraries or dependencies are required.
Security: Although chroot provides some level of isolation, it's not foolproof in terms of security. It was not designed as a security feature and should not be solely relied upon for containing malicious processes. Modern containerization technologies, like Docker, utilize more advanced mechanisms, such as Linux namespaces and cgroups, to provide stronger isolation.

Example:

Consider the following example:


mkdir mychroot
cp -r /bin /lib /lib64 /usr /mychroot
chroot /mychroot /bin/bash

In this example:

We create a directory called mychroot and copy essential binaries and libraries into it.
We use chroot to change the root directory to /mychroot.
After the chroot command, executing /bin/bash will run a Bash shell within the isolated environment.

Keep in mind that chroot by itself does not provide complete isolation; it is often used in conjunction with other tools and techniques to create more secure and robust containerized environments.
Prepare the Ubuntu Root Filesystem

now final this you will need before you start a filesystem .
we will use Docker to download Ubuntu filesystem

you will only need docker to download it , in your project root

$ docker run -d --rm --name ubuntu_fs ubuntu:20.04 sleep 1000
$ mkdir -p ./ubuntu_fs
$ docker cp ubuntu_fs:/ ./ubuntu_fs
$ docker stop ubuntu_fs

now we have ubuntu_fs inside our project , inside your main package

package main

import (
 "io/ioutil"
 "log"
 "os"
 "os/exec"
 "path/filepath"
 "strconv"
 "syscall"
 "strings"
 "fmt"
 "github.com/vishvananda/netns"

)



func main() {
 switch os.Args[1] {
 case "run":
  run(os.Args[2:]...)
 case "child":
  child(os.Args[2:]...)
 default:
  log.Fatal("Unknown command. Use run <command_name>, like `run /bin/bash` or `run echo hello`")
 }
}



func run(command ...string) {

 log.Println("Executing", command, "from run")
 cmd := exec.Command("/proc/self/exe", append([]string{"child"}, command[0:]...)...)
 cmd.Stdin = os.Stdin
 cmd.Stdout = os.Stdout
 cmd.Stderr = os.Stderr

 // Cloneflags is only available in Linux
 // CLONE_NEWUTS namespace isolates hostname
 // CLONE_NEWPID namespace isolates processes
 // CLONE_NEWNS namespace isolates mounts
 cmd.SysProcAttr = &syscall.SysProcAttr{
  Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS ,
  Unshareflags: syscall.CLONE_NEWNS | syscall.CLONE_NEWNET, 
 }

 // Run child using namespaces. The command provided will be executed inside that.
  must(cmd.Run())
}




func child(command ...string) {

 // Create cgroup
 cg()





 cmd := exec.Command(command[0], command[1:]...)

 cmd.Stdin = os.Stdin
 cmd.Stdout = os.Stdout
 cmd.Stderr = os.Stderr


 must(syscall.Sethostname([]byte("container")))


 must(syscall.Chroot("./ubuntu_fs"))
 // Change directory after chroot
 must(os.Chdir("/"))
 // Mount /proc inside container so that `ps` command works
 must(syscall.Mount("proc", "proc", "proc", 0, ""))
 // Mount a temporary filesystem
 if _, err := os.Stat("mytemp"); os.IsNotExist(err) {
  must(os.Mkdir("mytemp", os.ModePerm))
 }
 must(syscall.Mount("something", "mytemp", "tmpfs", 0, ""))




 must(cmd.Run())

 // Cleanup mount
 must(syscall.Unmount("proc", 0))
 must(syscall.Unmount("mytemp", 0))
}




func cg() {
 // cgroup location in Ubuntu
 cgroups := "/sys/fs/cgroup/"

 pids := filepath.Join(cgroups, "pids")
 containers_mini := filepath.Join(pids, "containers_mini")
 os.Mkdir(containers_mini, 0755)
 // Limit to max 20 pids
 must(ioutil.WriteFile(filepath.Join(containers_mini, "pids.max"), []byte("20"), 0700))
 // Cleanup cgroup when it is not being used
 must(ioutil.WriteFile(filepath.Join(containers_mini, "notify_on_release"), []byte("1"), 0700))

 pid := strconv.Itoa(os.Getpid())
 // Apply this and any child process in this cgroup
 must(ioutil.WriteFile(filepath.Join(containers_mini, "cgroup.procs"), []byte(pid), 0700))
}

func must(err error) {
 if err != nil {
  log.Printf("Error: %v\n", err)
   panic(err)
 }
}

this code introduced by Liz Rice

https://youtu.be/Utf-A4rODH8?si=ULuzE8E5N7N17dH9

youtube.com

Understanding the Code
1. Main Function

The main function serves as the entry point of the program. It uses command-line arguments to determine whether to run a new container or act as a child process within an existing container.

func main() {
    switch os.Args[1] {
    case "run":
        run(os.Args[2:]...)
    case "child":
        child(os.Args[2:]...)
    default:
        log.Fatal("Unknown command. Use run <command_name>, like `run /bin/bash` or `run echo hello`")
    }
}

Run Function

The run function sets up the container environment and executes a specified command inside it.

func run(command ...string) { log.Println("Executing", command, "from run") cmd := exec.Command("/proc/self/exe", append([]string{"child"}, command[0:]...)...) cmd.Stdin = os.Stdin cmd.Stdout = os.Stdout cmd.Stderr = os.Stderr cmd.SysProcAttr = &syscall.SysProcAttr{ Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS, Unshareflags: syscall.CLONE_NEWNS | syscall.CLONE_NEWNET, } must(cmd.Run()) }

this command cmd := exec.Command(“/proc/self/exe”, append([]string{“child”}, command[0:]…)…)
make sure that it’s append all command to same process
The Cloneflags specify the namespaces to be isolated (UTS, PID, and mount namespaces).
The Unshareflags further isolate the network namespace.
The cmd.Run() method runs the provided command within the created container.

Child Function

The child function is responsible for setting up the container filesystem and executing the specified command inside it.

func child(command ...string) {
    // ...
    cg()
    must(syscall.Sethostname([]byte("container")))
    must(syscall.Chroot("./ubuntu_fs"))
    must(os.Chdir("/"))
    must(syscall.Mount("proc", "proc", "proc", 0, ""))
    must(syscall.Mount("something", "mytemp", "tmpfs", 0, ""))
    must(cmd.Run())
    must(syscall.Unmount("proc", 0))
    must(syscall.Unmount("mytemp", 0))
}

The cg function sets up a control group (cgroup) to limit resource usage for the container.
Sethostname sets the hostname inside the container.
Chroot changes the root directory for the container.
Mount is used to mount essential filesystems like /proc and a temporary filesystem.
Finally, the command is executed within the container.

Control Groups (Cgroups)

The cg function creates and configures a cgroup for the container, limiting the number of processes.

func cg() {
 // cgroup location in Ubuntu
 cgroups := "/sys/fs/cgroup/"

 pids := filepath.Join(cgroups, "pids")
 containers_mini := filepath.Join(pids, "containers_mini")
 os.Mkdir(containers_mini, 0755)
 // Limit to max 20 pids
 must(ioutil.WriteFile(filepath.Join(containers_mini, "pids.max"), []byte("20"), 0700))
 // Cleanup cgroup when it is not being used
 must(ioutil.WriteFile(filepath.Join(containers_mini, "notify_on_release"), []byte("1"), 0700))

 pid := strconv.Itoa(os.Getpid())
 // Apply this and any child process in this cgroup
 must(ioutil.WriteFile(filepath.Join(containers_mini, "cgroup.procs"), []byte(pid), 0700))
}

Cgroups are used to control and limit resource usage for processes.
In this example, the cgroup limits the maximum number of processes to 20.

Error Handling

The must function is a simple utility function for handling errors.

func must(err error) {
    if err != nil {
        log.Printf("Error: %v\n", err)
        panic(err)
    }
}

If an error occurs, it is logged, and the program is terminated.
Building and Running the Container

To run the minimal container, follow these steps:

Build the executable: go build -o mycontainer main.go
Create a filesystem directory with an Ubuntu root filesystem, e.g., ubuntu_fs.
Run the container: sudo ./mycontainer run /bin/bash
remember you need to run it as sudo
your entry point is /bin/bash

now you are in your own minimal container , and now you have a deep understanding , may be if i have more time in the future i will add isolation layer on network , our you can do it , thank you for your time i hopped it helped anyone .

read this will help you more

namespace & golang a series of article explains namespace with go examples

“Creating Network Stacks and Connecting with the Internet” by “Shrikanta Mazumder”

https://songrgg.github.io/programming/linux-namespace-part01-uts-pid/

on next part we will create a network layer that give our container a virtual Ethernet in isolated subset that use host bridge as gateway . see you soon

part 2

you can find me on LinkedIn
https://www.linkedin.com/in/mohamed-elkerwash/

Understanding the Actor Design Pattern: A Practical Guide to Build Actor Systems with Akka in Java

mohamed alaaeldin — Sun, 28 Jan 2024 13:49:23 +0000

What is the Actor Model?
Overview of the Actor Model:

The Actor Model is a mathematical model for concurrent computation, introduced by Carl Hewitt in the 1970s. It views computation as a collection of independent entities called “actors” that communicate with each other by sending messages. Each actor has its own state, behavior, and a mailbox for receiving messages.
Key Characteristics:

Isolation: Actors operate independently, encapsulating their state and behavior.
Asynchronous Messaging: Communication between actors is achieved through asynchronous message passing.
Location Transparency: Actors can be distributed across different machines, providing a level of transparency regarding their physical location.
No Shared Memory: Actors do not share memory, avoiding the complexities of locks and shared data.

Key Concepts of the Actor Design Pattern Actors:

Actors are the fundamental units in the Actor Model. An actor is an autonomous entity that processes messages, maintains its own state, and can create new actors. Actors operate concurrently, making them well-suited for handling parallel and distributed tasks.
Messages:

Messages are the means of communication between actors. Actors send and receive messages asynchronously. Messages can contain data or instructions, allowing actors to exchange information and coordinate their activities.
Mailboxes:

Each actor has a mailbox that stores incoming messages. The actor processes messages sequentially, ensuring that its state changes in a controlled manner. Mailboxes help in managing the asynchrony of message passing.

Actor System:

An Actor System is the runtime environment that manages and coordinates actors. It provides the infrastructure for creating, scheduling, and supervising actors. Actor systems can span across multiple machines, forming distributed systems.

Actor Design Pattern in Action abstraction Creating Actors:

In most programming languages that support the Actor Model, creating an actor involves defining a class or function representing the actor’s behavior. Actors are instantiated within an actor system.

class MyActor(Actor):
    def receive(self, message):
        # Actor behavior goes here
        pass

Creating an instance of MyActor within an actor system

my_actor = actor_system.create_actor(MyActor)

Sending and Receiving Messages:

Actors communicate by sending and receiving messages. Sending a message to an actor is typically an asynchronous operation.

# Sending a message to an actor
my_actor.tell("Hello, Actor!")

# Actor receiving and processing messages
class MyActor(Actor):
    def receive(self, message):
        print(f"Received message: {message}")

Actor Lifecycle:

Actors have a lifecycle that includes creation, processing messages, and termination. Actor systems manage the lifecycle of actors and may provide hooks for initialization and cleanup.


class MyActor(Actor):
    def pre_start(self):
        # Initialization logic goes here
        pass

    def receive(self, message):
        # Actor behavior

    def post_stop(self):
        # Cleanup logic goes here
        pass

Concurrency and Parallelism with Actors Asynchronous Processing:

One of the strengths of the Actor Model is its support for asynchronous processing. Actors can continue processing messages while waiting for external events, improving overall system responsiveness.
Handling State:

Actors encapsulate their state, and state changes are managed through message processing. This isolation helps in avoiding shared mutable state, reducing the risk of concurrency issues.
Supervision and Fault Tolerance:

Actor systems often include mechanisms for supervision and fault tolerance. If an actor encounters an error, its supervisor can take corrective actions, such as restarting the actor or redirecting messages.

Practical Implementation of the Actor Model Choosing an Actor Framework:

Several programming languages offer libraries or frameworks for implementing the Actor Model. Popular choices include Akka for Scala/Java, Erlang OTP for Erlang, and Pykka for Python. Choose a framework based on your language of choice and the specific requirements of your project.
Designing Actor Systems:

When designing an actor system, consider the nature of the problem you are solving and how actors can collaborate to achieve the desired functionality. Identify the actors, their responsibilities, and the messages they exchange.
Case Study: Building a Concurrent System:

Let’s consider a simple example where actors represent different components of an e-commerce system — one actor for managing inventory, another for processing orders, and a third for handling customer notifications. These actors collaborate to ensure a smooth flow of e-commerce operations.

class InventoryManager(Actor):
    def receive(self, message):
        # Process inventory-related messages
        pass

class OrderProcessor(Actor):
    def receive(self, message):
        # Process order-related messages
        pass

class NotificationHandler(Actor):
    def receive(self, message):
        # Process notification-related messages
        pass

Challenges and Best Practices Scalability Considerations:

Design your actor system with scalability in mind. Distribute actors strategically, and leverage features provided by the actor framework for scalability, such as load balancing and clustering.
Avoiding Deadlocks and Race Conditions:

Carefully design message flows to avoid deadlocks and race conditions. Use appropriate synchronization mechanisms when actors need to coordinate their actions or share resources.
Testing Actor Systems:

Testing concurrent systems can be challenging. Leverage testing tools provided by the actor framework, and design tests that cover various scenarios, including message failures, actor restarts, and system recovery.
facts

The Actor Design Pattern offers a compelling approach to building concurrent and distributed systems. By embracing the principles of isolation, asynchronous messaging, and location transparency, developers can design systems that are scalable, responsive, and fault-tolerant. As you delve deeper into the Actor Model, explore different actor frameworks, and apply these concepts to real-world scenarios, you’ll unlock the full potential of this powerful paradigm in modern software development.
Choosing language and development framework

there are many framework like “AKKA , vertx.io both support java and Scala ”also Erlang/OTP
Erlang is a programming language used to build massively scalable soft real-time systems with requirements on high availability
in the last few months douglas crockford (the one who invent JSON) announced his language “Misty ” Misty Programming Language built for actor design pattern
https://www.youtube.com/watch?v=vMDHpPN_p08

worked with frameworks like “AKKA , vertx.io” i will use AKKA for this article you can still apply this concept on other frameworks .
A Practical Guide to Building Actor Systems with Akka in Java
What is AKKA

AKKA is a powerful toolkit and runtime for building highly concurrent, distributed, and fault-tolerant systems. At the heart of Akka lies the Actor Model, a paradigm that simplifies the development of concurrent and distributed applications. This tutorial aims to provide a step-by-step guide to building actor systems using Akka in Java.

Setting Up Your Project Adding Akka Dependency

Add the Akka dependency to your project’s build file. For Maven projects, include the following in your pom.xml:

<dependencies>
    <dependency>
        <groupId>com.typesafe.akka</groupId>
        <artifactId>akka-actor_2.13</artifactId>
        <version>2.6.16</version>
    </dependency>
</dependencies>

For Gradle projects, add the following to your build.gradle:

dependencies {
    implementation 'com.typesafe.akka:akka-actor_2.13:2.6.16'
}

Project Structure

Create a simple project structure with a main class to run your Akka actor system. For example:

src
└── main
    └── java
        └── com
            └── yourcompany
                └── yourproject
                    └── Main.java

Understanding Actors in Akka Actor Hierarchy

In Akka, actors form a hierarchy. Each actor has a parent and may have child actors. This hierarchical structure allows for efficient supervision and fault tolerance.
Defining an Actor

Create an actor by extending the AbstractActor class. Override the createReceive method to define the actor's behavior.

import akka.actor.AbstractActor;

public class MyActor extends AbstractActor {

    @Override
    public Receive createReceive() {
        return receiveBuilder()
                .match(String.class, message -> {
                    // Handle String messages
                    System.out.println("Received: " + message);
                })
                .build();
    }
}

Actor Lifecycle

Actors have a lifecycle with methods like preStart, postStop, and preRestart that you can override for initialization, cleanup, and error handling.

@Override
public void preStart() {
    // Initialization logic
    System.out.println("Actor started");
}


@Override
public void postStop() {
    // Cleanup logic
    System.out.println("Actor stopped");
}

Creating and Communicating with Actors ActorRef and ActorSystem

Create an instance of the ActorSystem and use it to create an ActorRef for your actor. The ActorRef is the entry point for interacting with the actor.

import akka.actor.ActorRef;
import akka.actor.ActorSystem;

public class Main {
    public static void main(String[] args) {
        // Create an ActorSystem
        ActorSystem system = ActorSystem.create("MySystem");

        // Create an ActorRef for MyActor
        ActorRef myActor = system.actorOf(MyActor.props(), "myActor");

        // Send a message to the actor
        myActor.tell("Hello, Akka!", ActorRef.noSender());

        // Shutdown the system
        system.terminate();
    }
}

Sending Messages

Use the tell method of the ActorRef to send messages to an actor.

// Sending a message to the actor

myActor.tell("Hello, Akka!", ActorRef.noSender());

Receiving Messages

Handle incoming messages in the actor’s createReceive method.

@Override
public Receive createReceive() {
    return receiveBuilder()
            .match(String.class, message -> {
                // Handle String messages
                System.out.println("Received: " + message);
            })
            .build();
}

Concurrency and Asynchronous Processing Handling State

Actors encapsulate their state. Ensure that state modifications are done within the actor’s behavior.

private String internalState = "";

@Override
public Receive createReceive() {
    return receiveBuilder()
            .match(String.class, message -> {
                // Handle String messages and modify state
                internalState = message;
                System.out.println("State updated: " + internalState);
            })
            .build();
}

Asynchronous Message Processing

Leverage Akka’s asynchronous nature for non-blocking message processing.

@Override
public Receive createReceive() {
    return receiveBuilder()
            .match(String.class, message -> {
                // Asynchronous processing
                getContext().getSystem().scheduler().scheduleOnce(
                        Duration.create(1, TimeUnit.SECONDS),
                        getSelf(),
                        "Delayed response",
                        getContext().getSystem().dispatcher(),
                        getSelf()
                );
            })
            .matchEquals("Delayed response", message -> {
                // Handle delayed response
                System.out.println("Received delayed response");
            })
            .build();
}

Supervision and Fault Tolerance Actor Supervision

Supervise actors by defining a supervisor strategy in the actor system.

import akka.actor.OneForOneStrategy;
import akka.actor.SupervisorStrategy;
import scala.concurrent.duration.Duration;

@Override
public SupervisorStrategy supervisorStrategy() {
    return new OneForOneStrategy(
            10, // maxNrOfRetries
            Duration.create("1 minute"), // withinTimeRange
            throwable -> SupervisorStrategy.restart() // decision
    );
}

Handling Failure

Actors can handle failures by restarting, stopping, or escalating the error to their supervisor. Override the preRestart method to implement custom restart logic.

@Override
public void preRestart(Throwable reason, Option<Object> message) {
    // Custom restart logic
    System.out.println("Restarting actor due to: " + reason.getMessage());
    super.preRestart(reason, message);
}

Testing Akka Actor Systems Unit Testing Actors

Use Akka’s TestActorRef for unit testing individual actors.

import akka.actor.ActorSystem;
import akka.testkit.TestActorRef;

public class MyActorTest {
    private final ActorSystem system = ActorSystem.create();

    @Test
    public void testMyActor() {
        // Create a TestActorRef for MyActor
        TestActorRef<MyActor> testActorRef = TestActorRef.create(system, MyActor.props());

        // Send a message and assert the result
        testActorRef.tell("Test Message", ActorRef.noSender());
        // Perform assertions on actor's behavior or state
    }
}

TestKit and TestActorRef

For more complex scenarios involving multiple actors and asynchronous communication, use Akka’s TestKit.

import akka.actor.ActorSystem;
import akka.testkit.javadsl.TestKit;
import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

public class MyActorSystemTest {

    private static ActorSystem system;

    @BeforeClass
    public static void setup() {
        system = ActorSystem.create();
    }

    @AfterClass
    public static void teardown() {
        TestKit.shutdownActorSystem(system);
    }

    @Test
    public void testActorSystem() {
        new TestKit(system) {{
            // Test actor system interactions
            // Send messages and assert the results
        }};
    }
}

Practical Example: Building a Simple Actor System Designing the System

Let’s design a simple actor system where an OrderProcessor actor communicates with a PaymentProcessor actor.
Implementing Actors

Define the OrderProcessor and PaymentProcessor actors.

public class OrderProcessor extends AbstractActor {
    @Override
    public Receive createReceive() {
        return receiveBuilder()
                .match(String.class, message -> {
                    System.out.println("Order received: " + message);
                    // Forward the order to the PaymentProcessor
                    getContext().actorOf(Props.create(PaymentProcessor.class)).forward(message, getContext());
                })
                .build();
    }
}

public class PaymentProcessor extends AbstractActor {
    @Override
    public Receive createReceive() {
        return receiveBuilder()
                .match(String.class, message -> {
                    System.out.println("Processing payment for order: " + message);
                    // Simulate payment processing
                    System.out.println("Payment processed successfully.");
                })
                .build();
    }
}

Running the System

Create an actor system and send an order message to the OrderProcessor.

public class Main {
    public static void main(String[] args) {
        // Create an ActorSystem
        ActorSystem system = ActorSystem.create("OrderProcessingSystem");

        // Create an ActorRef for OrderProcessor
        ActorRef orderProcessor = system.actorOf(Props.create(OrderProcessor.class), "orderProcessor");

        // Send an order message
        orderProcessor.tell("12345", ActorRef.noSender());

        // Shutdown the system
        system.terminate();
    }
}

Conclusion

This tutorial has provided a comprehensive guide to building actor systems with Akka in Java. By understanding the Actor Model, creating actors, handling concurrency, implementing fault tolerance, and testing, you are now equipped to build robust and scalable systems using Akka’s powerful toolkit. As you continue your journey with Akka, explore its documentation and features to unlock the full potential of this actor-based concurrency model in your projects.