From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 Date: Mon, 20 Apr 2020 18:44:42 +0400 From: Alexey Sheplyakov To: ALT Linux Team development discussions Message-ID: <20200420144442.GA11274@alexnuc> References: <3a76e0b2-059c-036f-d732-f4867a71018f@rosalinux.ru> <20200418142344.GA8584@alexnuc> <284386a0-c81c-d81b-98fe-d3a46ca5aa86@rosalinux.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <284386a0-c81c-d81b-98fe-d3a46ca5aa86@rosalinux.ru> User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [devel] =?utf-8?b?0J/QvtC90LjQttC10L3QuNC1INC/0YDQsNCyINGBIHJv?= =?utf-8?b?b3Qg0L3QtSDRgNCw0LHQvtGC0LDQtdGCINCyIGFsdC1wOC1yb290ZnMtc3lz?= =?utf-8?q?temd?= 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: Mon, 20 Apr 2020 14:44:54 -0000 Archived-At: List-Archive: List-Post: On Sat, Apr 18, 2020 at 06:37:55PM +0300, Mikhail Novosyolov wrote: > [root@pay2 /]# strace -f su - user -c /bin/bash 2>&1 | grep bin/bash > execve("/bin/su", ["su", "-", "user", "-c", "/bin/bash"], 0x7ffccf65b4a8 /* 30 vars */) = 0 > [pid 37104] execve("/bin/bash", ["-bash", "-c", "/bin/bash"], 0x12fa9a0 /* 17 vars */) = -1 EAGAIN (Ресурс временно недоступен) Единственная ситуация, когда exec* возвращает EAGAIN -- превышение лимита RLIMIT_NPROC. Подробности описаны в `execve() and EAGAIN` в man execve [1] Кратко: когда-то давно seteeuid, setresuid со товарищи возвращали ошибку при превышении лимитов ресурсов (тем UID, на который пытались переключиться). Тем самым создавая предпосылки для дыр имени sendmail setuid [2]. Разработчики ядра решили, что сброс привилегий всегда должен работать, и перенесли проверку RLIMIT_NPROC из set*[ug]id в exec*. С тех пор exec* в случае превышения числа процессов^W потоков возвращает EAGAIN. [1] http://man7.org/linux/man-pages/man2/execve.2.html [2] https://seclists.org/bugtraq/2000/Jun/98 # strace -f -e setuid,execve su -l user -s /bin/true execve("/bin/su", ["su", "-l", "user", "-s", "/bin/true"], 0x7ffd053a22c8 /* 31 vars */) = 0 strace: Process 5089 attached [pid 5089] +++ exited with 0 +++ --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=5089, si_uid=0, si_status=0, si_utime=0, si_stime=0} --- setuid(0) = 0 strace: Process 5090 attached [pid 5090] setuid(1000) = 0 [pid 5090] execve("/bin/true", ["-true"], 0x1de9c40 /* 18 vars */) = -1 EAGAIN (Resource temporarily unavailable) su: exec failed [pid 5090] +++ exited with 1 +++ +++ exited with 1 +++ А теперь уберем лимиты: # mv /etc/security/limits.d /etc/security/limits.d.NONONO И попробуем еще раз # strace -f -e setuid,execve su -l user -s /bin/true execve("/bin/su", ["su", "-l", "user", "-s", "/bin/true"], 0x7ffd7883da48 /* 31 vars */) = 0 strace: Process 5151 attached [pid 5151] +++ exited with 0 +++ --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=5151, si_uid=0, si_status=0, si_utime=0, si_stime=0} --- setuid(0) = 0 strace: Process 5152 attached [pid 5152] setuid(1000) = 0 [pid 5152] execve("/bin/true", ["-true"], 0x1135c40 /* 18 vars */) = 0 [pid 5152] +++ exited with 0 +++ +++ exited with 0 +++ Замечу, что в обоих случаях собственно сборс привилегий (setuid(1000)) прошел успешно. > Не. Дело не в ulimit. Возможно. Не хватает информации, чтобы сделать такой вывод (возможно, Вы поменяли зловредные настройки по умолчанию). И для обратного заключения тоже не хватает информации. Поделитесь, пожалуйста, 1) выводом strace -f -e setuid,execve su -l user -s /bin/true 2) выводом sudo -u user -i ulimit -a (в этом chroot'е) 3) содержимым /etc/security/limits.conf /etc/security/limits.d/*.conf 4) если Ваш UID в хост системе тоже 1000, то и выводом ps -T -u `whoami` | wc -l (в host системе) > В соседнем контейнере с запуском от UID=1000 нет проблем. Это именно в контейнере что-то не то. В контейнере или chroot'е? (А еще точнее, UID namespace есть?) И там ровно те же настройки (limits.d/*.conf и прочий PAM)? А запускаете одновременно оба chroot'а?