[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) |
Hello,
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))
(user-account
(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
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?
Ludo’.
- bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop, Jan, 2019/09/16
- bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop, Timothy Sample, 2019/09/17
- bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop, Jan, 2019/09/17
- bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop,
Ludovic Courtès <=
- bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop, Gábor Boskovits, 2019/09/19
- bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop, Ludovic Courtès, 2019/09/20
- bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop, Julien Lepiller, 2019/09/20
- bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop, Timothy Sample, 2019/09/20
- bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop, Ludovic Courtès, 2019/09/20
- bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop, Tobias Geerinckx-Rice, 2019/09/19