[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#37423: Changing the login service from GDM to SLiM and then back to

From: Ludovic Courtès
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:22:57 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)


Timothy Sample <address@hidden> 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:

diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 06d72b5f60..e87cb4d845 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -764,9 +764,10 @@ the GNOME desktop environment.")
 (define %gdm-accounts
-  (list (user-group (name "gdm") (system? #t))
+  (list (user-group (name "gdm") (system? #t) (id 900))
          (name "gdm")
+         (uid 900)
          (group "gdm")
          (system? #t)
          (comment "GNOME Display Manager 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 
                                              (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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]