From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 2B7C8158086 for ; Tue, 30 Nov 2021 00:56:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2DA262BC02C; Tue, 30 Nov 2021 00:55:58 +0000 (UTC) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E25822BC004 for ; Tue, 30 Nov 2021 00:55:57 +0000 (UTC) Received: by mail-ed1-x532.google.com with SMTP id y13so79384071edd.13 for ; Mon, 29 Nov 2021 16:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3BOvPqAExsvY++7AUFZaOKcTb+08aI1PE66XhBhKj8M=; b=Vxdhd4mF4Aox2Q8xLMGSkPksNkpeF6GJN+mgoZyZPBcSftKn0JHjc6821wtOu1c32V OFaNtckKK3irUE/3P519wbPjwMfFy7Ai/2yJ1Q4s2geU8Z2koQ4nx6apcLj9ScQPSyUx GHANUW0Rf1grEOymebVB9PnqkP+vSZ3wngF3rAlhJ7O68cBf8iPVI58+sfywAeoRjCnY lv9+YCy3noxU2VnJ1g/WBVpUBl87I8YI51Urz/ch0b5ygepVGRZXbmu8wmpdnyLSvdKG b1FVCX3uZJgBlAmnmv6+PHJzHM23elyYC25wxnDrdlF0m2k92IhrBH6mzVV1Y+RS+FTl dQtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3BOvPqAExsvY++7AUFZaOKcTb+08aI1PE66XhBhKj8M=; b=45g9faUkCut26pLMhqKez2lnAD7930J2Smb2LMx+TRLfraR2LLsohEN7e+rC8HEWEa +7z6nYhNkuWAxBUP/0wVVJ0SuFiRDRwbkIsSKvQojp2XYTwGhVZOOzZmckWznbvVXXIH GweZi/WDcYM1B0eZ0C39gjOUtIDB/Dk2k90OncDGVY+bLtRUaYB/dFjFm++SypwEdFSD W/fJUBNBhaHL7IQO2FipHrEZrwj9ainHXNWfVTrh98tmEXNknWSnnGc74Nxja7tzYB/G /YhAb65y0W4j2v0Z/L8dMl8bFKgLHrkOeBWO764QfDp6ThkGYI8ORYHTCzx/r7cfq94j S6Yw== X-Gm-Message-State: AOAM531jGv6ml91mI5M6TyktF33Up5gajdIQ5N8s9ohla1v/0Uo93Vfc 4deFFn+5Gim7VflrElfFtI9lBwXuxwMtpkHYhRS3SLdQGJk8pw== X-Google-Smtp-Source: ABdhPJxNoHG+/zfiMe94bz014qCuOOtJRuNQasTgWZUjA0BqxW728u7bD23R14FmAck+gBbwfa6idiCNvuPeG8QkUjs= X-Received: by 2002:a17:906:cd03:: with SMTP id oz3mr65173039ejb.252.1638233756580; Mon, 29 Nov 2021 16:55:56 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <6109f0b12899a0db92bf92d20f696bb0e54a0458.camel@gentoo.org> In-Reply-To: From: Alec Warner Date: Mon, 29 Nov 2021 16:55:45 -0800 Message-ID: Subject: Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo To: Ulrich Mueller Cc: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 209737f2-443b-45b8-a231-bb921be7efc2 X-Archives-Hash: 9a11e8f2cfe268658cd1ac2662b2dae9 On Mon, Nov 29, 2021 at 2:25 AM Ulrich Mueller wrote: > > >>>>> On Mon, 29 Nov 2021, Alec Warner wrote: > > > - If Gentoo adds an acct-user/foo user, and that user already exists > > on my system with the wrong UID: the eclass dies[0]. > > I don't think that's correct. The eclass will just use the already > existing UID then (except for the very few acct-user packages that > define ACCT_USER_ENFORCE_ID). > > > - If Gentoo adds an acct-user/foo user, with uid=12345, and that uid > > is assigned to a user on my system already, the eclass dies. > > Similar to above, the eclass will dynamically allocate another UID that > is free. Oh good I misread it, you are right; my apologies. > > > - Some environments are very old, and so real users have unexpected > > uids; this includes Gentoo itself. > > - Gentoo (the community) used to allocate UIDs to devs in the > > 500-1000 range and we have 17 active developers with UIDs in that > > range. So for example if we allocate one of these UIDs to an acct-* > > package; that package will not be installable on woodpecker without > > modification because those UIDs are already taken. > > See above. > > Also, why would one allocate UIDs in the 500..999 range (1000 is fine, > actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999. A bunch of reasons. - In the case of gentoo.org specifically I am guessing bugs and / or ignorance (as we discussed on IRC.) enewuser / useradd / the normal utilities lack the permissions to add users (because they cannot write to LDAP without credentials) and so currently we have a tool (perl_ldap); from 2006 onward it looks for the highest uidNumber in LDAP and adds 1 to it. I don't have the source code for earlier versions, but code comments implied the uids were entered by people; not machines. People are really bad at consistently allocating UIDs and are bad at following standards :) - In my previous work, the uid automation would routinely have bugs (we did not have good unit or functional testing) and often the uid range requirements were either not implemented (oops) or were buggy (also oops.) We often fixed weird bugs by hand (if we noticed that e.g. an account had some weird problem and it was someone's first day; redoing their account is cheap.) But if the bug was in the past; it was often too expensive to fix anything; so our user accounts had many exciting quirks of names, odd assignments, etc. This is why I say that conceptually the 'identity provider' is external to Gentoo (because we all have our weird site-specific quirks.) As you note above though, most acct-* packages will not break and will just assign some other uid / gid; so only the FORCE_ID packages matter and there are only 3 of those...so I mostly concede on that basis provided we avoid adding more FORCE'd packages. -A > > Ulrich