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, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 Date: Fri, 21 Apr 2023 15:50:53 +0300 From: "Alexey V. Vissarionov" To: ALT Linux Team development discussions Message-ID: <20230421125053.GA3677@altlinux.org> References: <20230420141519.4560389b@sem-nb2> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230420141519.4560389b@sem-nb2> Cc: gremlin@altlinux.org Subject: Re: [devel] UID_MIN/GID_MIN 500 -> 1000 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: Fri, 21 Apr 2023 12:51:02 -0000 Archived-At: List-Archive: List-Post: Good ${greeting_time}! On 2023-04-20 14:15:19 +0300, Mikhail Efremov wrote: > Есть мысль увеличить UID_MIN/GID_MIN по умолчанию до 1000, Не вижу никаких проблем. Еще и UID_MAX можно увеличить до 4294967294 - еще со времен ядер 2.4, что ли... в 2.6 уже точно 32-битные UID/GID были. > в апстриме А кто для нас апстрим? :-) > и во всех других дистрибутивах это давно уже сделано. Среди них уже давно нет хороших примеров для подражания. Отдельные решения срисовать - да, бывает полезно, но так, чтобы всерьез брать пример - увы. > Системных пользователей все больше и лучше иметь для них > пространство UID с запасом. При всем своем довольно большом опыте эксплуатации самых разных систем и сервисов я могу вспомнить всего один сервер из очень стародавних времен, где количество системных пользователей превышало сотню, и это было, мягко говоря, от бедности. Выйти за пределы пяти сотен... теоретически, наверное, возможно, но я с трудом представляю себе, как для этого надо загадить систему. > Единственной проблемой мне видится то, что нужно сохранить > текущие значения в /etc/login.defs при обновлении, переход > пользователей в системные может привести к неизвестным > побочным эффектам. Только если кто-то где-то сдуру принимает решение о системности пользователя исходя из диапазона, в который попадает его UID. Единственное очевидное исключение - root, но там UID проверяется не на принадлежность диапазону, а ноль или не ноль. В норме признаков (достаточных условий) системности пользователя всего два: 1. указанный шелл отсутствует в /etc/shells; 2. указанный домашний каталог не принадлежит пользователю. Иногда к ним относят отсутствие валидного encrypted password, но на это лучше не закладываться. Как и на любые другие параметры. > Если login.defs редактировался, то проблемы нет, он noreplace > и будет создан login.defs.rpmnew. А вот если не редактировался, > то значения UID_MIN/GID_MIN все равно надо бы сохранить старые. На существующих системах при обновлении - да, было бы неплохо. Хотя и не критично. > Мне в голову приходит только сохранять в файл в /tmp при > обновлении (в %pre) и восстанавливать в %post. Если у кого > есть идеи как это сделать лучше/проще, то с удовольствием > выслушаю. Так и делать. А перед восстановлением переименовать login.defs в login.defs.rpmnew - результат будет таким же, как и в случае модифицированного login.defs -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net