Hello,
Ludovic Courtès <
address@hidden> ezt írta (időpont: 2019. szept. 19., Cs, 23:24):
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:
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