Hello, Ludovic Courtès <l...@gnu.org> ezt írta (időpont: 2019. szept. 19., Cs, 23:24):
> Hello, > > Timothy Sample <samp...@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
