В Exim обнаружили критические уязвимости, позволящие выполнить на сервере произвольный код

пихать почтовую систему в докер я считаю маразмом, тут ты меня переубедить не сможешь. Может я и ретроград, но достаточно обосновано считаю, что почтарь - отдельная машина (пусть даже в виртуалке), которая больше ничем не занимается от слова совсем. Там крутится почта и сервисы вокруг нее вроде вебморды, админки и т.п.

Чем виртуалка принципиально лучше связки контейнеров?

Каждое приложение работает без привилегий в собственном контейнере, к каждому монтируется том для сохранения состояния, всё это отлично масштабируется при желании. Всякие вебморды и админки вообще можно держать в отдельных контейнерах.

Можно это хозяйство и на отдельной машине держать, кто мешает.

Когда всё в ансибле зафиксировано, это разворачивается за десять минут, вместе с получением сертификатов, DNS и всем таким прочим.

Может, ещё и LDAP в контейнере держать нельзя? 🤨

Я в очередной раз поражаюсь и не знаю, как реагировать на докернутых. Ответь на банальный вопрос. Отчего все мануалы и рекомендации по установке и настройке почтовых серверов начинаются с фразы «рекомендуется устанавливать на чистую установку»? Отчего, скажи-ка мне КРАЙНЕ не рекомендуется менять имя хоста, ПОСЛЕ установке почтовой системы? Каким образом, какие и почему записи в DNS могут влиять на все это? Потому как прочитав ваш рекостный и фееричный спич по почтари, сервисы каталогов и так далее в контейнерах у меня сложилось впечатление, что максимум для чего вы это все ставили - это эксперименты ради любопытства, или системы для полутора инвалидов. Которым, в том числе, до сиреневой звезды, попадут-ли их письма в спам адресату, или нет и дойдут-ли вообще…

все мануалы и рекомендации по установке и настройке почтовых серверов начинаются с фразы

Ни разу не видел.

«рекомендуется устанавливать на чистую установку»

Но чем контейнер не чистая установка?

Отчего, скажи-ка мне КРАЙНЕ не рекомендуется менять имя хоста, ПОСЛЕ установке почтовой системы?

Имя контейнерного хоста и не меняется. И имя контейнера тоже не меняется. Никакой почтовик извне никаким образом не в курсе, что почта приходит в контейнер с именем smtp-server, к примеру. В заголовках при отправлении разве что может быть информация, что письмо было переслано из одного контейнера в другой. Но никто никогда и не требовал, чтобы письмо не имело истории.

Как записи в DNS должны на это повлиять? Письмо приходит на mx.server.name и уходит с mx.server.name. Заголовки подписываются, политики работают. Антиспам адекватно фильтрует, письма отлично ходят. И к гуглу, и не к гуглу.

Как записи в DNS должны на это повлиять? Письмо приходит на mx.server.name и уходит с mx.server.name. Заголовки подписываются, политики работают. Антиспам адекватно фильтрует, письма отлично ходят. И к гуглу, и не к гуглу.

Вот, видимо, такие, с позволения сказать «специалисты», на данный момент работают в компании spotify.

Что до остальной ереси, что была написана тобой до этого. все это, конечно, прекрасно. Пока почтарь обслуживает пользователей, скажем так, до 50. А потом, начнутся неминуемые проблемы. Как ты свой контейнер - не масштабируй. Как я понимаю ты с почтовыми системами даже среднего размера - дел не имел, иначе не писал бы такой фееричной фигни.

Что до утверждений, что дескать «приложение работает без привилегий в собственном контейнере», то по отношению к нормальной почтовой системе данная писанина несколько смешна. Докернутые, как обычно, забывают, что контейнер никаким образом не дает гарантии полной изоляции.

Боже ж мой. Почтовик работает, почта ходит, все довольны.

Спросил же: где мне ждать проблем? Что вдруг может быть не так с DNS-записями?

В ответ одни претенциозные словеса про неминуемые проблемы, смешную писанину и фееричную фигню.

контейнер никаким образом не дает гарантии полной изоляции

Не даёт, я нигде и не писал обратного. Говорю, что приложения в контейнере я запускаю без эскалации прав. Или это тоже должно быть несовместимо с «нормальной почтовой системой»?

Есть что сказать по теме или только щёки надувать будем?

Тем не менее, все эти проблемы в итоге решили и современные компиляторы уже 25 лет такого не допускают. А в Си не только не исправили, но и не собираются, и гордятся этим. И да, в Фортране нельзя сложить строку с указателем и прибавить результат к действительному числу, а в Си сплошь и рядом такое происходит потому, что очередной автор имена переменных перепутал.

одновременно доступы к обоим массивам?

Не умели, точнее делали это по-простому, если массив размером 1, значит граница 1. Но, главное, что эти проверки появились позже. Если бы исходно компилятор это проверял, подобный код не считался бы рабочим. А рабочий код счётной программы лучше не править.

фортране не было типов «массив любой длины».

Это как посмотреть. В головной программе массив объявляся фиксированного размера, а в подпрограмме нет. И подпрограмма не могла узнать какого размера массив её передали. Можно было одим из параметров в подпрограмму передавать как-бы размер массива, но это просто переменная. Легко можно было написать п/п вида «суммируй числа из массива пока не встретится -1».

Плюс всем хотелось динамической памяти. По факту, большинство виденых мною компиляторов фортран 77 так или иначе поддерживали динамический массив, хотя в стандарте этого не было. Что было в более ранних компиляторах я не знаю, а те, а с кем общался не помнят.

Самое раннее, что гуглится по динамической памяти, — это компилятор EGTRAN, английский диалект FORTRAN II, примерно 1965 год, до появления Си. Документация не гуглится.

Изучая разный древний фортрановский код, можно найти всякие непонятные значки вместо размера массива или ещё что — то ли следы каких-то расширений стандарта фортрана, то ли для самописных препроцессоров.

После прочтения встревожился. Но после вывода результата команды aptitude show exim4:

Состояние: не установлен

успокоился.

Открой для себя зимбру и не имей себе мозг

Спасибо - имел опыта вытаскивания писем из БД зимбры. Больше не хочу. Я старовер - предпочитаю чтобы почта была в Maildir.

Может я и ретроград, но достаточно обосновано считаю, что почтарь - отдельная машина (пусть даже в виртуалке), которая больше ничем не занимается от слова совсем.

У меня так и есть - один Mailu в докере на виртуалке и всё. Для остальных личных контейнеров у меня другие виртуалки. Докер там только для того чтобы это всё скопом само обновлялось, а не для того чтобы рядом напихать кучу другого говна.

Это решили в другом ЯП. Из современного Фортрана выкинули часть возможностей исходного, а другую часть объявили устаревшей. Того кода, который FORTRAN IV, не осталось, его весь переписали. И это спорный вопрос, хорошо или плохо, когда под одним названием прячутся совсем разные языки.

нельзя сложить строку с указателем и прибавить результат к действительному числу

Это то здесь при чем? Подобная ошибка вылезет достаточно быстро, а тут речь про неконтролируемое переполнение буфера/выход за границы массива. Такая «дырявость» памяти была нормой для ЯП времён появленя Си. Это мой исходный посыл, сравнивать фичи Фортрана и Си я не собирался.

Есть сборочная система, есть список зависимостей и то, как они должны быть установлены. Выполнено? Если да, и сборочные скрипты писал не идиот, то всё соберется.

Ты писал-читал сборочные скрипты к сложным прогам, да? При всём желании, рукописная природа сишной сборки помноженная на разнообразность окруждений сборки дают солидную вариантивность, которую не всегда получается обуздать. И я еще раз напоминаю, что мы обсуждаем clang-analyzer, который должен идеально повторить этот самый рукописный алгоритм сборки, но без самой сборки. Зачем далеко ходить — но моем текущем проекте 90% файлов собираются с некими общими опциями, а дальше 10% — каждый со своими. Удачи натягивать это на clang-analyzer.

Использование языковой конструкции = сломанное? Ты вообще Си знаешь, или теоретизируешь просто? Ты понимаешь, что именно делает volatile?

Я уже писал, что в Си НЕ БЫЛО volatile, оно появилось достаточно поздно, чуть раньше выхода стандарта C89, в который оно уже попало.

Вот, видимо, такие, с позволения сказать «специалисты», на данный момент работают в компании spotify.

А можно немного историй? Я слышал, что Spotify гордятся своими микросервисами, как пользователь я регулярно страдаю от того, как Spotify глючит, но никаких твердых улик против них у меня нет. А у кого нынче софт не глючит? Вот у MS коды подтверждения логина ходят по 2 часа и только в папку «спам» — и ничо, вроде микросервисами там не гордятся.

и что мешало вызов функций сделать в стиле pascal в winapi все функции так объявлены, и зачем то сделали строки в самом дурацком стиле, не делали бы, люди бы написали свои.

Ты писал-читал сборочные скрипты к сложным прогам, да?

Под сборочными скриптами я понимаю сорта конфигов и декларативных описаний для разных систем сборки, если ты не понял. Но это всё абсолютно не важно.

И я еще раз напоминаю, что мы обсуждаем clang-analyzer, который должен идеально повторить этот самый рукописный алгоритм сборки, но без самой сборки.

Да? Точно-точно? А вот мануал по clang-analyzer с тобой не согласен:

To analyze a project, scan-build simply sets the environment variable CC to the full path to ccc-analyzer. It also sets a few other environment variables to communicate to ccc-analyzer where to dump HTML report files.

Никто в здравом уме не стал бы заниматься тем, чтобы переписывать логику существующих сборочных систем, которых сильно больше десяти.

Я уже писал, что в Си НЕ БЫЛО volatile, оно появилось достаточно поздно, чуть раньше выхода стандарта C89, в который оно уже попало.

И? Как это делает оптимизатор сломанным? Потому что ты так решил? Это, разумеется, чушь. Видишь ли, мы не в розовом мире живем, и для части оптимизаций подсказки компилятору таки необходимы. А учитывая, что эта оптимизация работает в большинстве случаев, требуя volatile лишь для частного, предположение было хорошим и покрывает большинство кейсов. Можешь полюбопытствовать и посмотреть, как часто volatile используется в ядре или musl. Спойлер: довольно редко. Удивительно, почему? Ведь язык сломан!

Докеробесие - это такая болезнь. Правильно ответили.

Друг, не поверишь… я даже видел, что в отдельный докер пихали получение сертификата letsencrypt. Во!

и что мешало вызов функций сделать в стиле pascal в winapi все функции так объявлены, и зачем то сделали строки в самом дурацком стиле, не делали бы, люди бы написали свои.

Вторая фундаментальная ошибка в Си — это хранение «клички кота» рядом с жизненно важными сущностями, что в композиции с отсутствием инструментов контроля границ буфера дает восхитительные результаты.

Под сборочными скриптами я понимаю сорта конфигов и декларативных описаний для разных систем сборки, если ты не понял. Но это всё абсолютно не важно.

Если ты не сможешь нужный файл поместить в нужную именно ему среду, то даже лучший в мире парсер не сможет его разобрать. Именно благодаря наличию препроцессора, который разбавляет собой простоту сишного синтаксиса.

Да? Точно-точно? А вот мануал по clang-analyzer с тобой не согласен:
Никто в здравом уме не стал бы заниматься тем, чтобы переписывать логику существующих сборочных систем, которых сильно больше десяти.

Ты назваешь этот трюк «просто»? Я не спорю с тем, что это «возможно», но это не «просто».

Можешь полюбопытствовать и посмотреть, как часто volatile используется в ядре или musl. Спойлер: довольно редко. Удивительно, почему? Ведь язык сломан!

Я вообще-то именно на ядро ссылку и дал. Примерно 20-30 тысяч использований. И даже указал, что volatile на самом деле не решил проблему интерпретации ссылок, потому имеются атомарные функции и блоки asm volatile — атомарные функции так-то тоже по всему ядру применяются, даже больше, чем asm volatile.

Я так и не понял, ты хочешь обсудить вопрос анализируемости сишной программы, или тебе понравилось обсуждать вопрос про происхождение volatile и смежных модификаторов?

Друг, не поверишь… я даже видел, что в отдельный докер пихали получение сертификата letsencrypt. Во!

Ну может быть эту команду было легко зашедулить и проконтролировать уже имеющимися средствами? Я вот через баш тоже много чего запускаю, но не потому, что баш такой удобный, а потому, что он просто сразу есть.

Это скользкий вопрос. Код Фортрана 77 компилируется и поныне, уже 45 лет как. Код Си89 многие компиляторы брать не хотят, либо надо изощряться с флагами. При этом в Фортране давно нет проблем с утечками памяти, а в Си есть.

И да, Си++ Страуструпа и современный Си++, даже если взять 11 стандарт, а не более новые, — это очень сильно разные языки вплоть до того, как там предлагается выделять память. Так что это не только проблема Фортрана. Возражение, что их можно смешивать в одном коде, не принимается, потому что в фортрановском проекте тоже могут соседствовать f77 и f90 файлы.

По поводу сложения указателей — согласен, что это другая проблема, но не согласен, что она всегда легко замечается. Но исходная беда — общая, связанная с осознанным распиздяйством, которое путают с оптимизацией и которое ложится на благодатную почву, потому что сам язык кривой.

Потому что на нем почти никто не пишет.

Вы в курсе сколько людей работает над проектом?

Какие с моей стороны могут быть возражения? Вы либо не умеете читать, либо специально троллите.

Фортран 95 и Фортран 66

Если хотите Фортран 77, смотрите что запретили в Фортран 2018. Если компилятор кладёт на требования стандарта и берёт код с запрещёнными в стандарте операторами, то это только пока разрабы компилятора добрые. В любой момент в этом или другом компиляторе запреты стандарта могут быть реализованы.

Код Фортрана 77 компилируется и поныне

Чистого Фортран 77 толком не существовало, уже в 80-е очень была нужна динамическая память, пусть без realloc, но хотя бы один раз определить размер массива в run-time. В компиляторах был разнобой по реализации массивов переменного размера. Просто взять исходник большой f77 программы с дискеты и скомпилить его не получится. Отдельные подпрограммы да, а PROGRAM нет.

В целом, весь этот посыл бред. Утечка памяти не должна вести к выполнению прозвольного кода. Это проблемма аппаратная и ОС, а не ЯП. Почему считается нормальным, что программа на асме может работая с данным перетереть адрес возврата в стеке? И, если это считается нормальным для асма, то должно быть и в Си, он высокоуровневый асм и не более.

Но не в Си придумали плоскую модель памяти, хранение локальных переменных в стеке. Си как раз спокойно генерит код для разных микроконтроллеров, где гарвардская архитектура, своеобразный стек и т.д. И только в мире x86 считается, что проблемы нужно лечить софтом, типа патчи против meltdown, проверки на выход за границы массива и т.д.

ЕМНИП, у i8080 можно было аппаратно отделить стек, у него на одной из ног появлялся строб при PUSH/POP/CALL/RET. Нигде не использовалось, память дорогая, пусть всё в одном пространстве будет. В защищённом режим i80386 и дальше, выход за границы сегмента не возможен. Но где использовались не совпадающие сегменты кода, данных, стека?

Код Си89 многие компиляторы брать не хотят

А что в стандартах убрали, кроме Implicit int in declarations и Implicit function declarations? Это в Cи2023 убирают K&R-стиль определения функций.

Если ты не сможешь нужный файл поместить в нужную именно ему среду, то даже лучший в мире парсер не сможет его разобрать.

Смешались в кучу кони, люди. Парсер не имеет никакого отоншения к сборочной среде и не зависит от нее. Обратное, очевидно, ложь. GCC и Clang не требуют для использования какого-то конкретного тулчейна, а одинаково хорошо работают как с чистыми мейкфайлами, так и с мезонами и цмейками.

Ты назваешь этот трюк «просто»? Я не спорю с тем, что это «возможно», но это не «просто».

Ты точно со мной споришь, а не с голосами в своей голове? Ткни пальцем, где я говорил, что это «просто». Я лишь подсветил факт того, что ты просто плаваешь в теме, в которую влез, и не понимаешь, как работаел clang-analyze. Сначала ты утверждал, что сборку надо реализовывать в анализаторе, а когда оказалось, что не надо - начал вилять жопой и рассказывать, что все равно это сложно.

Примерно 20-30 тысяч использований.

На целое ядро. И в основном этот volatile сконцентрирован вокруг аппаратных регистров. Потому что потоки и ввод-вывод прекрасно справляются без него.

тебе понравилось

Мне понравилось, как ты вертишься, как уж на сковородке, придумывая одну небылицу за другой.

Ух ты. Целый движок огнелиса – это «ничего не пишут». Ну ок, не пишут так не пишут

Но не в Си придумали плоскую модель памяти, хранение локальных переменных в стеке. Си как раз спокойно генерит код для разных микроконтроллеров, где гарвардская архитектура, своеобразный стек и т.д. И только в мире x86 считается, что проблемы нужно лечить софтом...

Проблемы Си не закончиваются на стэке, и делать Си настолько плохим было не обязательно для высокоуровневого асма — проблемы отсутствия проверок выхода за границы и использования нуль-терминированных строк аппаратным стэком не решаются. Структуры данных большого размера в регистры не засунешь, эта проблема архитектурой не решается.

Я согласен с тем, что организация стэка в процессорах PDP ужасная, но это лишь вишенка на торте. Более того, x86 был создан адаптированным конкретно под Си c сишными массивами и конкретно строками, в том числе там был аппаратный поиск нуль-терминатора (REPZ) — именно потому я говорю, что x86 был куском дерьма очень давно, но его до сих пор тащят по инерции.

Парсер не имеет никакого отоншения к сборочной среде и не зависит от нее.

Парсер не может сделать НИЧЕГО, пока не получит корректный текст на входе. Вот тебе сишная программа, парси ее:

#include "defs.h"
AT_INIT
MAIN_LOOP(DEFAULT_HANDLER)
AT_FINI

Я лишь подсветил факт того, что ты просто плаваешь в теме, в которую влез, и не понимаешь, как работаел clang-analyze. Сначала ты утверждал, что сборку надо реализовывать в анализаторе, а когда оказалось, что не надо - начал вилять жопой и рассказывать, что все равно это сложно.

В нашей компании твое поведение называется «долюбиться до столба». Clang-analyzer встраивается в систему сборки через ccc-analyze, да, он это делает, ты подтвердил мои слова, но каким-то образом выражаешь несогласие со мной. Тебе заняться нечем?

На целое ядро. И в основном этот volatile сконцентрирован вокруг аппаратных регистров. Потому что потоки и ввод-вывод прекрасно справляются без него.

Потому что потоки работают на атомарный фукнциях с volatile семантикой. Одна из них:
https://elixir.bootlin.com/linux/latest/A/ident/READ_ONCE
А потом WRITE_ONCE, а потом функции работы с блокировками, RCU, и прочие примитивы, итого «всего-лишь» 100-200 тысяч на всё огромное ядро.

Парсер не может сделать НИЧЕГО, пока не получит корректный текст на входе.

Я тебе давал выдержку из мануала, который объясняет, каким образом анализатор получает корректный текст. Это работающий оптимальный способ. Настолько, что проблемы «распарсить си для анализа» в реальности не существует. Прочитай еще раз, если не понял.

В нашей компании твое поведение называется «долюбиться до столба».

Лол. Бред от некомпетентности несешь ты, а когда я это закономерно подсветил - объявляешь, что я долюбился до столба.

да, он это делает, ты подтвердил мои слова,

Это были МОИ слова, клоун. Это ТЫ утверждал, что анализатор должен повторять и реализовывать сборочную систему, после чего получил от меня по кумполу выдержкой из мануала и начал вилять жопой.

А потом WRITE_ONCE, а потом функции работы с блокировками, RCU, и прочие примитивы, итого «всего-лишь» 100-200 тысяч на всё огромное ядро.

А беда-то в чем? Ты так и не показал, ПОЧЕМУ это является проблемой. Мне нужна конкретика, а не твои фантазии.

Это ТЫ утверждал, что анализатор должен повторять и реализовывать сборочную систему, после чего получил от меня по кумполу выдержкой из мануала и начал вилять жопой.

Я написал ровно то, что написал:
В Exim обнаружили критические уязвимости, позволящие выполнить на сервере произвольный код (комментарий)

clang-analyzer, который должен идеально повторить этот самый рукописный алгоритм сборки

Идеально повторяет? Идеально повторяет. Это не «просто»? Это не «просто». Какие вопросы?

А беда-то в чем? Ты так и не показал, ПОЧЕМУ это является проблемой.

Что «это» является какой «проблемой»? Я даже честно пытался уточнить, про что конкретно мы спорим, но ты упорно продолжаешь унижать собственную шизу, иногда дублируя процесс текстом здесь. И мне это уже начинает надоедать.

Я написал ровно то, что написал

Да, именно это:

И я еще раз напоминаю, что мы обсуждаем clang-analyzer, который должен идеально повторить этот самый рукописный алгоритм сборки, но без самой сборки.

Еще раз тебя спрашиваю: зачем ему повторять алгоритм сборки, если анализатор вставляется в CC и вызывается как компилятор?

Идеально повторяет? Идеально повторяет.

Он ничего не повторяет, его вызывает сборочная система.

Это не «просто»? Это не «просто».

Потому что ты скозал?

Что «это» является какой «проблемой»?

Мы обсуждали volatile. Я понимаю, что у тебя памяти хватает только на два комментария, но ты уж постарайся осмыслить наш диалог.

не осуждаю, но какие ваши агрументы?

тоже самое слышно отовсюду и про БД в контейнерах, но их пихают и никто не умер.

хотелось бы конкретики.

Zhbert обновление информации: https://www.openwall.com/lists/oss-security/2023/10/01/4

Походу всё не так страшно, большинство уязвимостей таки локальные. Хотя это несколько расходится с заявлениями ZDI.

Если сервер не использует NTLM (вроде что-то ненужное) и EXTERNAL (а это что такое вообще?) аутентификации, не стоит за какими-то проксями (где такое используют?), не использует для резолвинга левые днсы потенциальных аттакеров (например 8.8.8.8), и не использует spf в acl (а вот это уже может быть где-то) - то уязвимости не работают.

я даже видел, что в отдельный докер пихали получение сертификата letsencrypt. Во!

Я даже подозреваю где именно:

https://eff-certbot.readthedocs.io/en/stable/install.html#alternative-1-docker

Спасибо, добавил в шапку.

Это 1 программа, причем от разработчиков языка. Что ещё, не считая ПО proof-of-concept.

А что касается самого Exim - что ж, лучше него еще ничего не придумали. Тот второй, который postfix - боль, головная боль, жопоболь.

А не бред? postfix же умеет в milter. Да и Sendmail никто не отменял. :-)

Он же на сишее написан. Чего вы ещё ожидали?

Вот и остались одни мышевозилы гуёвые...

Бугагага. Почтарь в контейнере… Вот уж воистину «докер головного мозга». Нет, я видел всякое. Я даже видел маразм, когда в контейнер пихали томкат. Но вот почтарь….

smtp-сервер вполне может быть и в контейнере, и вовсе на отдельной железке. Это вот хранилку, которая pop/imap, в контейнер особо не запихаешь, если там на большой объём рассчитывать. Но и то есть варианты.

Пошла демагогия. А бэкенд дискорда тоже не считается?

Считается. Что ещё?

Redox, например

https://en.wikipedia.org/wiki/Ruffle_(software)

Это и есть proof-of-concept — ПО, что не имеет практического применения, и написано по иным причинам.

Есть практическое применение, но весьма ограниченное, и по сути проект энтузиастов.

Пока почтарь обслуживает пользователей, скажем так, до 50

Не любитель контейнеров как способа деплоя софта, ныне очень модного, для чего, собственно, все эти контейнеры сейчас так массово и юзаются абизянами. Это когда на каждую софтину тянется системное окружение в несколько сот мегов. Но справедливости ради, контейнеры, вернее сервисы запущенные в контейнерах, без проблем даржат любую нагрузку, прекрасно масштабируются в пределах хоста и утилизируют его ресурсы. Практически нет никакой разницы, запущен ли процес в контейнере или в непосредственно в OS.

когда на каждую софтину тянется системное окружение в несколько сот мегов

Если для всего используется один и тот же базовый образ, это системное окружение тянется ровно один раз.

Понятно, что поверх базового образа всегда ещё что-то ставится, но в целом это такие копейки, которые можно не считать.

Удобно, опять же, когда можно тюнить окружение под каждую софтину отдельно и не делать себе голову на ровном месте.

Если для всего используется один и тот же базовый образ, это системное окружение тянется ровно один раз.

Эт чо тогда после установки пары десятков наносервисов в контейнерках, упакованных из одного и того же base-container закидыванеим туда пары rpm пакетов с наносервисами, размеры /var/lib/docker или /var/lib/containerd разрастаются до нескольких десятков гигабайтов? А если эти контейнерки начать обновлять, то десятки гигабайтов превращаются в сотни.

разрастаются до нескольких десятков гигабайтов

На самом деле как посмотреть.

Можно посмотреть так, и будет ужас-ужас:

# du -sh /var/lib/containers/storage/overlay
21G	/var/lib/containers/storage/overlay

А можно посмотреть так, и совсем другое дело:

# du -shx /var/lib/containers/storage/overlay
7.5G	/var/lib/containers/storage/overlay

Слово overlay как бы намекает нам в чём тут цимес.