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

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

Ubuntu 26.04 (или ядро с бэкпортом из 7.0.0-41+, включая облачные сборки вроде linux-aws и linux-azure);

kernel.apparmor_restrict_unprivileged_unconfined=1 (в 26.04 это значение по умолчанию);

containerd или Docker со стандартным AppArmor-профилем - то есть почти любой Kubernetes, k3s, RKE2 или Docker-хост.

Операция kill: (…) получает Permission denied внутри контейнера при совпадающем uid и выключенном seccomp;

gosu (и любой Go-бинарь, вызывающий setuid) крутится на 100% CPU, но сервис не стартует и логов нет;

PostgreSQL: получает ошибку could not signal for checkpoint: Permission denied;

Сообщения в журнале ядра вида: apparmor="DENIED" operation="signal" … peer="cri-containerd.apparmor.d//&unconfined".

Штатная ситуация: необходимо изменить ресурсы CPU и RAM на нод группе виртуальных машин в Kubernetes кластере. Запуск Terraform кода проходит штатно, машины поднимаются корректно, все замечательно. Однако несколько подов PXC (Percona Operator for MySQL) не могут стартануть. В логах стандартная просьба инициализировать процесс восстановления через команду:

Чего? Сначала исключаем очевидное. Shell от kubectl exec и PID 1 работают под одним uid 1001 (mysql), capabilities пустые у обоих, Seccomp: 0. По правилам Unix сигнал должен проходить.