From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor?= Boskovits Subject: bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop Date: Thu, 19 Sep 2019 23:47:58 +0200 Message-ID: References: <20190916005154.41b74430@interia.pl> <871rwf5y49.fsf@ngyro.com> <87ftksvv4e.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000decbab0592eee8c4" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:57455) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iB4IR-0002qf-Os for bug-guix@gnu.org; Thu, 19 Sep 2019 17:49:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iB4IP-0001dD-QA for bug-guix@gnu.org; Thu, 19 Sep 2019 17:49:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:47708) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iB4IP-0001d5-ND for bug-guix@gnu.org; Thu, 19 Sep 2019 17:49:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iB4IP-0001hd-J3 for bug-guix@gnu.org; Thu, 19 Sep 2019 17:49:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87ftksvv4e.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 37423@debbugs.gnu.org --000000000000decbab0592eee8c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Ludovic Court=C3=A8s ezt =C3=ADrta (id=C5=91pont: 2019. szep= t. 19., Cs, 23:24): > Hello, > > Timothy Sample skribis: > > > Could this be the same issue as ? In short= , > > Guix doesn=E2=80=99t guarantee that the =E2=80=9Cgdm=E2=80=9D user will= have the same UID if it > > gets deleted and recreated (which happens when you remove the GDM > > service and add it again). You can fix this by ensuring the owner of > > the files under =E2=80=9C/var/lib/gdm=E2=80=9D is the current =E2=80=9C= gdm=E2=80=9D user. > > If you just (1) configure with GDM, (2) reconfigure without GDM, and (3) > reconfigure with GDM again, I would expect the original UID of =E2=80=98g= dm=E2=80=99 to > be reused in step #3, as long as it has not been reallocated in the > meantime (for instance because the user created other accounts.) > > We could address this by fixing the UID and GID of the =E2=80=98gdm=E2=80= =99 user: > > > However, looking at the allocation routines in (gnu build accounts), I > think that this would forcefully set =E2=80=98gdm=E2=80=99 to 900/900 on = existing > installations, even if 900 is already used by another account: > > --8<---------------cut here---------------start------------->8--- > scheme@(gnu build accounts)> (allocate-groups (list (user-group (name > "foo")(id 10))) > vlist-null > (list (group-entry > (name "foo") (gid > 20)))) > $2 =3D (#< name: "foo" password: #f gid: 10 members: ()>) > --8<---------------cut here---------------end--------------->8--- > > That=E2=80=99s a valid policy (declaration prevails over state), but it d= oes > mean that we can=E2=80=99t really apply the above patch. > > (Or we could use much lower UID/GID numbers, which are less likely to be > taken=E2=80=A6) > > Thoughts? > > Couldn't we simply do what the fix does: ensuring the owner of the files under =E2=80=9C/var/lib/gdm=E2=80=9D is the current =E2=80=9Cgdm= =E2=80=9D user? > Ludo=E2=80=99. > That would solve this issue, without actually fixing the UID and GID. Best regards, g_bor --=20 OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21 --000000000000decbab0592eee8c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Ludovic Court=C3=A8s <ludo@gnu.org> ezt =C3=ADrta (id=C5=91pont: 2019. szept= . 19., Cs, 23:24):
Hello,

Timothy Sample <s= amplet@ngyro.com> skribis:

> Could this be the same issue as <https://bugs.gnu.org/36508>= ;?=C2=A0 In short,
> Guix doesn=E2=80=99t guarantee that the =E2=80=9Cgdm=E2=80=9D user wil= l have the same UID if it
> gets deleted and recreated (which happens when you remove the GDM
> service and add it again).=C2=A0 You can fix this by ensuring the owne= r of
> the files under =E2=80=9C/var/lib/gdm=E2=80=9D is the current =E2=80= =9Cgdm=E2=80=9D user.

If you just (1) configure with GDM, (2) reconfigure without GDM, and (3) reconfigure with GDM again, I would expect the original UID of =E2=80=98gdm= =E2=80=99 to
be reused in step #3, as long as it has not been reallocated in the
meantime (for instance because the user created other accounts.)

We could address this by fixing the UID and GID of the =E2=80=98gdm=E2=80= =99 user:


However, looking at the allocation routines in (gnu build accounts), I
think that this would forcefully set =E2=80=98gdm=E2=80=99 to 900/900 on ex= isting
installations, even if 900 is already used by another account:

--8<---------------cut here---------------start------------->8---
scheme@(gnu build accounts)> (allocate-groups (list (user-group (name &q= uot;foo")(id 10)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 vlist-null
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 (list (group-entry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(name "foo")=C2=A0 (gid = 20))))
$2 =3D (#<<group-entry> name: "foo" password: #f gid: 10= members: ()>)
--8<---------------cut here---------------end--------------->8---

That=E2=80=99s a valid policy (declaration prevails over state), but it doe= s
mean that we can=E2=80=99t really apply the above patch.

(Or we could use much lower UID/GID numbers, which are less likely to be taken=E2=80=A6)

Thoughts?


Couldn't we simply do what the fix= does: ensuring the owner of
the files under =E2=80=9C/var/lib/gdm=E2=80=9D is the current =E2=80=9Cgdm= =E2=80=9D user?
=C2=A0
Ludo=E2=80=99.

That would solve this issue, without= actually fixing the UID and GID.


Best regards,
g_bor
--
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4= DBF:3719:0367:2506:A96C:CF63:0B21
--000000000000decbab0592eee8c4--