From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 15 19:06:24 2021 Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 23:06:24 +0000 Received: from localhost ([127.0.0.1]:39523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXB44-000525-MT for submit@debbugs.gnu.org; Thu, 15 Apr 2021 19:06:24 -0400 Received: from world.peace.net ([64.112.178.59]:41330) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXB41-00051o-38 for 36508@debbugs.gnu.org; Thu, 15 Apr 2021 19:06:24 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lXB3u-0002Zm-Ox; Thu, 15 Apr 2021 19:06:14 -0400 From: Mark H Weaver To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#36508: GDM files have incorrect owner after temporarily removing service In-Reply-To: <878s5j8ga7.fsf@gnu.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <875z0pgnqn.fsf@gnu.org> <87lf9jiems.fsf@netris.org> <878s5j8ga7.fsf@gnu.org> Date: Thu, 15 Apr 2021 19:04:30 -0400 Message-ID: <87wnt3gndy.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36508 Cc: Brendan Tildesley , 36508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Ludovic, Ludovic Court=C3=A8s writes: > IDs as hash of the user names are interesting because that=E2=80=99d be > stateless (conversely, the current ID allocation strategy is stateful: > it arranges to not reuse recently-freed IDs.) > > But like you write, we=E2=80=99d need 32-bit UIDs. In libc, =E2=80=98uid= _t=E2=80=99 > (specifically =E2=80=98__UID_T_TYPE=E2=80=99 in typesizes.h) is 32-bit, s= o it might work > rather well in user space. The kernel and core system components certainly support 32-bit UIDs, and have for around 20 years. > It still sounds like a change with significant implications though, and > it=E2=80=99s hard to predict exactly how it would go or what would break. Right, my concern is with the vast majority of programs and libraries in Guix, most of which probably haven't seen much (if any) testing with large UIDs. > For example, that does away with the system/non-system ranges, and > wouldn=E2=80=99t play well with =E2=80=9Cspecial=E2=80=9D IDs like 0 and = 65535. This particular issue is easily addressed. It's easy enough to find a function from 31-hash values to 32-bit IDs that's injective and avoids any chosen subset of special IDs, as long as there are fewer than 2^31 special IDs. Simply adding 65536 (or even 2^31) to the hash value would be one easy option. What do you think? Mark