GNU bug report logs - #37423
Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop

Previous Next

Full log

View this message in rfc822 format

From: Gábor Boskovits <boskovits <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Timothy Sample <samplet <at> ngyro.com>, 37423 <at> debbugs.gnu.org
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 part 1 (text/plain, inline)]

Hello,

Ludovic Courtès <ludo <at> gnu.org> ezt írta (időpont: 2019. szept. 19., Cs,
23:24):

> Hello,
>
> Timothy Sample <samplet <at> ngyro.com> skribis:
>
> > Could this be the same issue as <https://bugs.gnu.org/36508>?  In short,
> > Guix doesn’t guarantee that the “gdm” 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 “/var/lib/gdm” is the current “gdm” 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 ‘gdm’ 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 ‘gdm’ user:
>
>
> However, looking at the allocation routines in (gnu build accounts), I
> think that this would forcefully set ‘gdm’ 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 = (#<<group-entry> name: "foo" password: #f gid: 10 members: ()>)
> --8<---------------cut here---------------end--------------->8---
>
> That’s a valid policy (declaration prevails over state), but it does
> mean that we can’t really apply the above patch.
>
> (Or we could use much lower UID/GID numbers, which are less likely to be
> taken…)
>
> Thoughts?
>
>
Couldn't we simply do what the fix does: ensuring the owner of
the files under “/var/lib/gdm” is the current “gdm” user?


> Ludo’.
>

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


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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.