From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 21 Nov 2021 16:37:08 +0300 From: "Dmitry V. Levin" To: devel@lists.altlinux.org Message-ID: <20211121133707.GA10803@altlinux.org> References: <97dfb53d-ed5d-3c8f-dbcf-d427646b9889@basealt.ru> <20211120121149.GB27513@altlinux.org> <6bd4cbca3eb21b04052c2b4dbfb0ec84d4d62b93.camel@altlinux.org> <2c07adc3-d0df-f19e-8179-348f32dc7632@rosalinux.ru> <3e1dfc4a9661414edf338311c5afab8e81a2077d.camel@altlinux.org> <20211121100038.GA8487@altlinux.org> <20211121125201.7j2ld4vkeeei5r7l@example.org> <20211121130016.GB10220@altlinux.org> <20211121131500.hlgdfikjw6wt66bn@example.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211121131500.hlgdfikjw6wt66bn@example.org> Subject: Re: [devel] =?koi8-r?b?W0VybGFuZ10gz8fSwc7J3sXOycUgzsEgy8/Myd7F09TX?= =?koi8-r?b?zyDQz9TPy8/XINcg4czY1MU=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2021 13:37:08 -0000 Archived-At: List-Archive: List-Post: On Sun, Nov 21, 2021 at 02:15:00PM +0100, Alexey Gladkov wrote: > On Sun, Nov 21, 2021 at 04:00:16PM +0300, Dmitry V. Levin wrote: > > On Sun, Nov 21, 2021 at 01:52:01PM +0100, Alexey Gladkov wrote: > > > On Sun, Nov 21, 2021 at 01:00:38PM +0300, Dmitry V. Levin wrote: > > > > On Sun, Nov 21, 2021 at 11:59:26AM +0300, Nikolay A. Fetisov wrote: > > > > > В Сб, 20/11/2021 в 21:15 +0300, mikhailnov@ пишет: > > > > > > 20.11.2021 18:04, Nikolay A. Fetisov пишет: > > > > > > > ... > > > > > > > > > > > > > Механизм ulimit про namespaces ничего не знает, ограничения в > > > > > > > security/limits.d/50-defaults.conf считаются по процессам _всех_ > > > > > > > контейнеров. Как итог, можно получить срабатывение ulimit внутри > > > > > > > полупустого контейнера на, например, запуск задачи по cron. > > > > > > Почему? cron же пропустит задачу через PAM-стек, а pam_limits > > > > > > выставит лимиты, ... > > > > > > > > > > ... А дальше ядро сосчитает количество процессов данного UID и сравнит > > > > > с лимитами. А считаются как минимум до текущего в p10 std-def 5.10.72 > > > > > включительно _все_ процессы без учёта их распределения по namespaces. > > > > > В результате, имея для примера пару контейнеров с работающими  > > > > > 255 процессами пользователя, в третьем получаем превышение > > > > > RLIMIT_NPROC. Хотя у контейнеров nproc по-умолчанию 512, > > > > > а в хост-системе, например, поднят до 1024. > > > > > Реально у меня это проявилось на двух машинах с где-то 50 контейнерами > > > > > каждая. > > > > > > > > > > Так это поведение известное, хотя и неочевидное. Исправление уже есть, > > > > > см. https://lkml.org/lkml/2021/2/22/207 - но в наших ядрах как минимум > > > > > в p10 и ниже этого патча нет. > > > > > > > > Серия изменений v5.14-rc1~153^2~2, призванная решить эту проблему, > > > > в качестве побочного эффекта позволяет любому непривилегированному > > > > пользователю превышать ограничения RLIMIT_NPROC и нескольких других > > > > лимитов путём создания userns и переноса в них своей активности. > > > > > > Дим, твоя фраза в водит в заблуждение. Пользователь внутри userns не может > > > превысить RLIMIT_NPROC из родительского userns. НИкакого превышение > > > невозможно. > > > > Я говорю о том, что непривилегированный пользователь с помощью userns > > может создать процессы, число которых многократно превышает RLIMIT_NPROC. > > Нет. Дим, ты не понял этот патчет. > > При создании userns rlimit_proc (не только он, а все привязанные к > пользователю) пользователя записывается в userns как max. При создании > процесса проверка лимита происходит рекурсивно вверх по дереву userns и > если где-то max превышен, то всё. Ты не сможешь превысить в userns свой > собственный rlimit_proc. > > Этот патч позволяет _уменьшить_ rlimit_proc в одном userns без поломки > соседнего userns от такого же пользователя. Хорошо, если так. В таком случае до этого изменения userns-контейнеров не существовало, а то, что называли userns-контейнерами, было чистым маркетингом. -- ldv