Hacker News Digest

Контейнеры — это не виртуальные машины, а обычные процессы, запущенные ядром хоста с особыми ограничениями. Их можно найти даже в /proc. При этом в Linux нет отдельной функции «контейнеры»: это набор из пяти механизмов ядра — пространства имён скрывают видимость, cgroups ограничивают ресурсы, а сеть изолируется отдельной магией.

Образы — это просто папки, которые Docker куда-то кладёт и делает их новым корнем процесса через chroot или pivot_root. При запуске docker run -it --rm ubuntu /bin/bash Docker скачивает образ, размещает его и выполняет /some/weird/docker/path/bin/bash.

Любопытно, что Go плохо подходит для среды выполнения контейнеров. runc написан на Go, но его многопоточная среда мешает: многие системные вызовы требуют однопоточности, поэтому перед инициализацией Go запускается специальный модуль на C. Кроме того, в Go нет полноценного fork — он копирует только главный поток, поэтому runc обходит это через запуск /proc/self/exe с особым аргументом. Наконец, Docker обычно требует прав root, так как многие API ядра исторически доступны только суперпользователю; без root приходится переписывать весь сетевой стек в пользовательском пространстве.

Обсуждение дополняет статью техническими деталями, отмечая, что успех Docker обусловлен не самой контейнеризацией (chroot и namespaces были известны ранее, например в OpenVZ), а созданием экосистемы и удобного DX: Dockerfile с послойной сборкой и кэшированием, а также реестром образов, что упростило CI и развертывание. В ходе дискуссии возникли следующие тезисы: — @jlhawn уточняет, что runc написан не полностью на Go, так как важные части реализованы на C. — Использование Go в рантаймах создавало проблемы с наследованием конфигураций namespaces и cgroups из-за переключения горутин между потоками. — Podman считается более современным и легким решением, так как он rootless и не требует демона и сокета. — @kazinator рекомендует отлаживать процессы в контейнере через gdb извне, используя /proc и переключая корень файловой системы. — Сетевая часть остается самой сложной из-за специфических правил IPTables и необходимости использовать slirp для обработки пакетов в userspace. — @sreekanth850 критикует «карго-культ» вокруг Docker, утверждая, что в ряде задач автоматизация развертывания без контейнеров эффективнее.

DeepSeek Elastic Compute (DSec) — это масштабируемая песочница для обучения агентных систем, объединяющая несколько уровней изоляции (FnCall, контейнеры, microVM, полные VM) через единый SDK. Платформа управляет размещением и жизненным циклом песочниц в кластере, используя независимо версионированные слои для быстрой сборки окружений. Для высокой плотности выполнения DSec комбинирует совместное использование памяти, её реклейм и гибкое CPU-планирование, а образцы данных загружаются по требованию из распределённой файловой системы Fire-Flyer File System (3FS).

DSec спроектирован совместно с фреймворком обучения с подкреплением, разделяя выполнение состоятельных роллаутов и прерываемое обучение на GPU. Это позволяет сохранять состояние агентов во время роллаутов, даже когда простаивающие ресурсы reclaimются для обучения. Платформа также активно противодействует нежелательному поведению агентов, такому как reward hacking, через контроль среды и изоляцию. В production один юнит DSec охватывает ~160 узлов, обслуживая около 3 миллионов песочниц в день, поддерживая более 380 тысяч одновременных песочниц и выдерживая более 5 тысяч созданий песочниц в секунду. Эти механизмы снижают накладные расходы на инициализацию окружений и распространение образов, повышают эффективность использования памяти и сохраняют низкую латентность даже при высокой степени переcommit ресурсов.

DSec заявляет о 380 000 одновременно работающих песочниц на 160 серверах с EPYC, что соответствует примерно 12 песочниц на ядро — подтверждая чрезвычайно высокую плотность вычислений. Длинный список авторов в статье обусловлен ограничением интерфейса arXiv; полный список доступен в PDF, это не скрытая стратегия. Платформа сравнивается с Google Ax как scheduler над Firecracker и микровиртуальными машинами. По мере роста возможностей моделей безопасные и изолированные среды становятся критически важными для предотвращения выхода ИИ за пределы песочницы. Нагрузка на песочницы сильно варьируется: многие простаивают, что усложняет предсказание ресурсных потребностей при большом количестве песочниц. Некоторые комментаторы рассматривают длинный список авторов как защиту талантов, другие — как обычную практику в крупном экспериментальном исследовании. Поднимается вопрос, что узким местом для масштабных агентных ройов будет не количество песочниц, а пропускная способность инференса. Упомянутые объёмы — петабайты слоёв, ~250 TB RAM, 3 млн запусков песочниц в день — указывают на модель, близкую к serverless, для обучения и RL‐агентов.

Языковая модель с 4 миллиардами параметров была дообучена с помощью supervised fine-tuning и agentic reinforcement learning для генерации планов выполнения SQL-запросов в PostgreSQL, которые работают быстрее, чем планы, выбранные стандартным оптимизатором. На этапе SFT модель научилась генерировать корректные планы для 14 из 113 ранее неразрешимых запросов, а после RL — для всех 113. В результате среднее время выполнения запросов сократилось на 44,7% по сравнению с планами PostgreSQL, а в лучших случаях — до 81%. Для устранения шума измерений был создан специальный стенд с изолированными контейнерами и минимизацией влияния кэша страниц Linux. Для обучения в шумной среде разработана модификация алгоритма GRPO, а обучение распределено между арендованным узлом с двумя H100 (для vLLM и тренера) и локальными четырьмя контейнерами PostgreSQL. Кроме того, использовано off-policy дистиллирование из 500 траекторий агента GPT-6 Astra для стабилизации обучения. Подход подтверждает, что даже небольшие открытые модели могут обучаться превосходить традиционные оптимизаторы в задачах с однозначной метрикой качества — временем выполнения запроса.

Обсуждение ставит под сомнение практическую ценность LLM‐оптимизатора: заявленные 81 % ускорения получены на небольшом наборе (8 ГБ, полностью в памяти), их масштабируемость и экономическая эффективность не доказаны, а риски галлюцинаций и повышенных затрат могут превзойти выгоду. Большинство участников советуют более простые и проверенные подходы: правильное индексирование, классическое ML, гибридные решения и ускорение самого PostgreSQL. Некоторые считают LLM‐подход слишком грубым и ресурсоёмким, предлагая целенаправленные нейросетевые эвристики (похожие на AlphaGo) или видя потенциал LLM в генерации планов. Критики отмечают, что 81 % ускорения не сравнимо с более чем 3‐кратным выигрышем без модели, а затраты на H100 и API могут превысить выгоду. Важно проверять планы, сгенерированные LLM, в изолированной копии продакшн‐БД, чтобы убедиться в ускорении типичных запросов и отсутствии регрессий. Для снижения риска галлюцинаций рекомендуется запускать LLM несколько раз и выбирать лучший план, либо использовать его как подсказку традиционному оптимизатору. Гибридный подход — выбор между традиционным оптимизатором и LLM‐моделью с последующим взятием лучшего плана — рассматривается как более практичный. Также советуют включать опцию RECOMPILE в хранимых процедурах для решения регрессий без LLM. Время планирования является критическим фактором: улучшения планов должны учитывать суммарное время планирование + выполнение. Классические методы ML (модели предсказания стоимости планов) считаются более подходящими, чем крупные языковые модели, для оптимизации запросов. Некоторые предлагают ускорять сам PostgreSQL через CUDA для более прямого прироста производительности. Простое, но часто забываемое правило — правильно индексировать данные; без этого любые улучшения планов будут ограничены.

Strix обнаружил активный GitHub personal access token с правами администратора в публичном образе контейнера Baseten, доступном через их Harbor-реестр. Токен принадлежал сервисному аккаунту basetenbot и предоставлял полный доступ к основным репозиториям продукта, GitOps и Homebrew tap, а также к приватным репозиториям клиентов. Образ, содержавший токен, был собран в марте 2023 года и оставался уязвимым до июля 2026 года — более трёх лет. Strix обнаружил его за 25 минут автономного сканирования без учётных данных или доступа к исходному коду.

Baseten отреагировал оперативно: к следующему дню они сделали Harbor-проект приватным и ротировали скомпрометированный токен, подтвердив критичность уязвимости. Инцидент подчеркивает риски оставления секретов в слоях контейнеров и избыточных прав у сервисных токенов. Авторы рекомендуют регулярно сканировать образы на секреты, ограничивать права токенов по принципу наименьших привилегий и использовать автономные агенты вроде Strix для проактивного поиска уязвимостей в собственной инфраструктуре.

Утечка токена произошла из-за хранения секретов в Docker-образах, а не из-за сложной атаки. Baseten оперативно устранила уязвимость без компрометации данных клиентов. Токен оставался активным более трёх лет (с марта 2023 по июль 2026), что указывает на отсутствие политики ротации PAT и использование бессрочных токенов — классическая ошибка. Уязвимость была обнаружена простым сканированием Docker-образов, а не AI-агентом. Любой детерминированный пентест-инструмент мог это сделать. Использование Docker build-аргументов для секретов небезопасно. Следует использовать build secrets с флагом --provenance=false для удаления метаданных. Baseten профессионально отреагировала: ротировала токен, удалила образ, сотрудничала с Strix и подтвердила отсутствие эксплуатации по логам. Спор: Strix запустила агента без согласия на домене клиента — одни считают это нарушением этики, другие — стандартной пентест-практикой при проверке поставщиков. Спор: Strix использовала AI-агент как маркетинговый ход — одни видят в этом рекламу уязвимости, другие — корректное раскрытие, улучшившее отраслевую безопасность. Совет: Все секреты, включая GitHub-токены, должны иметь короткий срок жизни и автоматически ротироваться — ежемесячно, а в будущем — ежечасно. Совет: Не храните проприетарные репозитории, GitOps-конфигурации или CI/CD-пайплайны на GitHub — это как оставлять ключи от дома на улице, особенно при наличии частных альтернатив. Совет: SOC2 Type II или HIPAA не гарантируют отсутствия базовых ошибок вроде хранения токенов в образах. Аудит должен проверять фактическую реализацию, а не только документы. Совет: Секреты в Docker-сборке должны изолироваться через build secrets, а не через build args — иначе они остаются в слоях и доступны всем с доступом к реестру. Сложность не в том, что AI-агент нашёл то, что человек не смог — а в том, что человек не стал проверять историю сборки Docker-образов, хотя это элементарно и критично. Инцидент подчеркивает: большинство утечек происходят из-за простых, известных и предотвратимых ошибок — неограниченных токенов и публичных образов с секретами. Совет: Регулярное сканирование публичных реестров контейнеров на секреты — обязательная практика для любой компании, заботящейся о репутации и безопасности клиентов. Baseten не была единственной жертвой — подобные утечки происходят ежедневно, но редко публикуются, так как компании их скрывают, а агенты не публикуют отчёты. Совет: Для защиты необходимо внедрять автоматическое сканирование образов на секреты на этапе сборки и блокировать публикацию образов с любыми следами токенов.

Cloud in a Bottle — это открытая платформа для личного облака, которая делает самохостинг простым и приятным, как использование смартфона. Она запускает веб-приложения в изолированных rootless-контейнерах на Ubuntu-машине, обеспечивая безопасность и минимальные изменения в существующем ПО. В отличие от простых хостеров контейнеров вроде Coolify, Cloud in a Bottle предоставляет интегрированную платформу: единый вход, общий доступ к данным между приложениями и единый дашборд для управления. Цель — создать ощущение «облачного смартфона», где установка и использование приложений так же просты, как в закрытых сервисах, но без слежки, рекламы и привязки к корпорациям.

Платформа включает curated каталог приложений с высоким порогом качества, хотя сейчас он небольшой и растёт еженедельно. Управление доступно через веб-интерфейс, поддерживается бесконтактный вход во все приложения после авторизации, а также механизмы безопасного обмена данными между ними. Проект полностью открыт, без телеметрии, и может быть развёрнут самостоятельно на VPS, локальном железе или виртуальной машине. Также предлагается управляемый вариант от компании Imbue с бесплатным кредитом — он использует тот же код и служит бизнес-моделью для поддержки open-source версии. Авторы видят в Cloud in a Bottle способ вернуть цифровую суверенность пользователям и стимулировать создание удобного открытого ПО для широкой аудитории, а не только для технических энтузиастов.

Самохостинг остаётся сложным из-за резервного копирования, доступа к белым IP и доменам, а также долгосрочной поддержки — даже при упрощённой установке пользователи не справляются дольше 3–4 лет из-за износа оборудования и энтропии. Потеря данных без надёжного восстановления — главная причина отказа от проектов; многие не хотят управлять бэкапами вручную, нужен автоматизированный механизм. Без двух машин и репликации самохостинг не решает проблему отказоустойчивости. Совет из прода: каждый сервис должен иметь отдельный sidecar-бэкап, иначе координация между компонентами (например, в Immich) становится неподъёмной. Авторитетный DNS на порту 53 мешает использовать Cloudflare и CDN, что критично для пользователей, заботящихся о безопасности. Ограничения провайдеров и бюрократия при получении белого IP и домена остаются барьером. Пользователи с 2 ГБ ОЗУ и 1–2 ядрами сталкиваются с нестабильностью при запуске нескольких сервисов на одном VPS. Проект теряет уникальность: Cloudron, SelfPrivacy, FreedomBox, Proxmox + community-scripts.org уже предлагают аналогичные функции. Отсутствие Home Assistant и Immich в каталоге приложений — существенный недостаток. Многие предпочитают Tailscale Aperture и exe.dev за простоту подключения и интеграцию с AI, а не изолированные контейнеры. AI-агенты уже помогают в настройке и диагностике, делая самохостинг доступнее для нетехнических пользователей. Для массового принятия нужна мобильная версия с настройкой домена и оплатой с телефона, но это конфликтует с правилами магазинов приложений. Отдельно: часть пользователей обвиняет авторов в спаме в репозиториях без раскрытия связи с проектом, что ставит под сомнение этичность продвижения.

В Omarchy до версии 4.0.1 по умолчанию пользователь входил в группу docker, что позволяло любому процессу в его сессии получать root-привилегии через доступ к сокету Docker. Docker-демон работает от root и слушает /var/run/docker.sock; члены группы docker могут взаимодействовать с этим сокетом, запуская контейнеры с монтированием хост-файловой системы и выполняя код от имени root. Это означало, что даже обычные приложения — браузеры, редакторы, IDE, npm-скрипты или AI-агенты — могли быть использованы для полного захвата системы без пароля или sudo. Проблема была усугублена тем, что настройка была opt-out, а документация вводила в заблуждение, подразумевая rootless-режим, хотя на самом деле предоставляла полный доступ к root. Эксплойт демонстрировался чтением /etc/shadow через docker run -v /:/hostroot. Исправление выпущено в версии 4.0.1; пользователям рекомендуется обновиться немедленно. Для тех, кто хочет избежать root-доступа при работе с контейнерами, предлагается использовать Podman — daemonless-альтернативу, работающую в пользовательских неймспейсах без привилегий.

Тред расширяет статью в нескольких направлениях: ставит под сомнение практическую значимость LPE через docker-группу на десктопе, указывает на давно документированный риск docker-сокета и существование rootless-альтернатив (Podman, rootless Docker), сообщает о других конкретных проблемах Omarchy (vibecoded-установщики, USB-дескрипторы в shell, win11-скрипт с plain-text паролями, неаудированные плагины), и фиксирует защиту как минимум одним пользователем с годовым опытом — частично подтверждая позицию лагеря, что вопрос не столько в Omarchy, сколько в культуре дефолтов десктопных дистрибутивов.

• Совет: @lrvick: любое приложение от имени пользователя способно перехватить пароль sudo через подмену функции в ~/.bashrc и exfiltration, поэтому sudo на десктопе — театр безопасности независимо от docker-эскалации.

• Спор: @mike_hearn утверждает, что root на Linux-десктопе мало что значит, так как пользовательский код уже контролирует ~/.bin, PATH и терминал: «If you run code as yourself on Linux it owns you». Оппоненты (@pibaker, @hashstring, @pkulak) считают, что дефолтное членство в docker-группе — это явное игнорирование документации Docker и Podman по работе rootless.

• Совет: @WhyNotHugo: rootless Docker стабилен уже более 4 лет, и он сам упаковывал его в AUR — использование rootful-демона на пользовательском десктопе необоснованно.

• Несколько участников (@kodoman, @exitb, @po1nt, @arjie) указывают, что docker-группа с rootful-сокетом — широко распространённая практика по всей экосистеме, и проблема не уникальна для Omarchy; статья лишь подсветила общий антипаттерн десктопов.

• @darkwi11ow, @SamInTheShell, @arjie и @WhyNotHugo: Podman / rootless Docker — стандарт в 2026 и поставляются rootless из коробки; @SamInTheShell по опыту отмечает: «sudo pacman -S podman не принёс этих проблем из коробки и предполагал rootless по умолчанию».

• Совет: @concinds обращает внимание на предыдущий похожий баг (commit 9285b19d6a72) — USB-дескрипторы передавались прямо в shell — и на этом основании рекомендует избегать vibecoded-дистрибутивов в принципе.

• Совет: @ruby_curmudgeon: плагины на plugins.omarchy.org запускаются полностью несакседжированными и без аудита, что усиливает риск-профиль Omarchy за пределами дефолтного пользователя.

• Совет: @felixfurtak по опыту установки: скрипт win11-docker в Omarchy сохраняет логин и пароль Windows-VM в открытом виде в конфиге — второй конкретный security-инцидент помимо статьи.

• Совет: @teravor: на текущий момент нет ни одного Linux-дистрибутива, где безопасно запускать приложения «как есть», так как у них есть доступ к /home; практика — профили bubblewrap для каждого приложения.

• Часть критики (включая @hashstring, @concinds, @archole) фокусируется не на конкретном CVE, а на «vibecoded»-происхождении дистрибутива: по их мнению, это системная проблема зрелости, а не единичный баг.

• Совет: @andrewvc: после того как на машине хотя бы раз запускали vibe-coding, он перестаёт доверять системе в целом и использует полностью отдельный физический хост для LLM-агентов.

• Совет: @trentnix противопоставляет критике скорость фикса: docker-проблема была зарепорчена и быстро закрыта — по его мнению, «система сработала хорошо», а Omarchy — удобный путь попробовать hyprland и дать детям машину с агентным сопровождением.

• Несколько участников (@vinniepukh, @yoyohello13) указывают на исторический прецедент LARBS от Luke Smith 8–10 лет назад — цикл «controversial personality + WM install script» повторяется; @yoyohello13 в итоге вернулся на KDE после оптимизаций тайлинга.

• Совет: @PaulHoule: для десктопа «root» давно не самое ценное — важнее credentials к git-репозиторию, postgres, облачным API и keyring, поэтому LPE-через-docker сам по себе менее критичен, чем кажется из CVE-заголовка.