Unable to log into X session via gdm

  • Done
  • quality assurance status badge
Details
5 participants
  • bokr
  • Danny Milosavljevic
  • Marius Bakke
  • Maxim Cournoyer
  • Maxime Devos
Owner
unassigned
Submitted by
Danny Milosavljevic
Severity
normal
D
D
Danny Milosavljevic wrote on 29 Nov 2020 14:02
(address . bug-guix@gnu.org)
20201129140240.546b1403@scratchpost.org
The latest guix system reconfigure (of yesterday) left me unable to login into
my X session. guix system rollback DID NOT fix it.

I would enter my password and it would "try" to login and return right back to
the gdm login screen.

I've since removed gdm from my OS configuration (because I have to do actual
*work* on this computer), but I think it would have been enough to just
chown /var/lib/gdm and rm ~/.xsession-errors (!) in order to make it work
again.

Does that mean that user ids are non-reproducible?

Why not have user_id = hash(user_name) ? Then they *are* reproducible.

(I've tried finding the spot where those user accounts are generated/updated
but so far have been unable to)

Anyway, this is just to record the problem and workaround. I won't do
further research on this problem on it on this computer.

The "gdm" system account is gone by now because I've removed gdm from the
OS configuration--and I don't plan on adding it ever again.

For reference, in order to remove gdm from the system configuration in
/etc/config.scm, do:

(1) Replace %desktop-services by
(remove (lambda (service) (eq? (service-kind service) gdm-service-type)) %desktop-services)

(2) Add (service slim-service-type) to SERVICES in /etc/config.scm

(3) guix system reconfigure /etc/config.scm
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/Dm/AACgkQ5xo1VCww
uqVhCQf/WsQedB2SJcRyggzFVgIbfBon1o08ZsjharOZ6iP6yj+PQRW63T/Nkwqm
M4+QKlvXnhKiiotmQWi7skAje5eYW4uVt47TUTBr9+++4EEJh5aTlnWg2wf1Q9Z3
DgQRJxxjH6U1cn8J1gBFW2tFmrTrM0ONAtB9BPohAh5Kz70c9FiUTimVsl+GwA0t
rpLxVXRvTs/Hiox/fx5R4UueVYeFoNKJ/OuOrdMeamkyOqrx+cZX50+7mdUZIGU0
xod0fOxRf9Gj+ZT4cJY9FeLrn6Xq1rs06MSLe6HD9D/6RuvA1T6bhk8G23LFeVML
RXY9vgUWfTqdSk1mQBfXqJgz5A5XIw==
=rut2
-----END PGP SIGNATURE-----


M
M
Marius Bakke wrote on 29 Nov 2020 18:00
87blfg14jn.fsf@gnu.org
Danny Milosavljevic <dannym@scratchpost.org> skriver:

Toggle quote (6 lines)
> The latest guix system reconfigure (of yesterday) left me unable to login into
> my X session. guix system rollback DID NOT fix it.
>
> I would enter my password and it would "try" to login and return right back to
> the gdm login screen.

Can you find any clues in the log files as to why this happened?

Did you reboot after reconfiguring?
-----BEGIN PGP SIGNATURE-----

iQFDBAEBCgAtFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl/D07wPHG1hcml1c0Bn
bnUub3JnAAoJEKKgbfKjOlT6SjsH/jwmnCLdB8ajkVi+2IwqDzlD3TzBYtwkXHHm
8ZFgvgzpdPY+4JDWRSzCjzjWSeYeVQKNdrze2HeiCUivOmEVmv604PUZt26EDoXl
6OKH9UpbTVadxnDUfVm+0fjhgg1a6OfeTwJwzsPwJFd9AOfA/pOuWzfUoU4Zcuwc
4WBYg6sAmERxKNhyTzgy5ADaOoHP5Hh0OaT0ROXLe/5V/kOq5BoRfGtk9neOLRSa
q8sQNjCtawNNriP46VS0gI+XFDh9SBKEJiDihock7c3M1y+BKZsfsnKwHqUFRp84
mGQlXw82BfljCx0IOlZBGJ/ZUDo4YvlhxWv9VAtgA+myqhd1elM=
=IpiW
-----END PGP SIGNATURE-----

D
D
Danny Milosavljevic wrote on 29 Nov 2020 22:20
(name . Marius Bakke)(address . marius@gnu.org)(address . 44944@debbugs.gnu.org)
20201129222020.7a804daa@scratchpost.org
Hi,

On Sun, 29 Nov 2020 18:00:44 +0100
Marius Bakke <marius@gnu.org> wrote:

Toggle quote (10 lines)
> Danny Milosavljevic <dannym@scratchpost.org> skriver:
>
> > The latest guix system reconfigure (of yesterday) left me unable to login into
> > my X session. guix system rollback DID NOT fix it.
> >
> > I would enter my password and it would "try" to login and return right back to
> > the gdm login screen.
>
> Can you find any clues in the log files as to why this happened?

I did check, but there were not really good clues in the logs, among other
things because it seemed that ~/.xsession-errors did not get updated. ls
did report that ~/.xsession-errors belongs to me, but it still didn't update
it, which is why I then removed it. But I only did that after removing gdm
as well, so I don't know whether removing gdm or removing ~/.xsession-errors
or both fixed it.

Checking the logs again, I have only this interesting line:

Toggle quote (5 lines)
>Nov 29 04:24:26 localhost gdm: GdmDisplay: Session never registered, failing


> Did you reboot after reconfiguring?

I had selected the older system generation in the grub boot menu.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/EEJQACgkQ5xo1VCww
uqWYOQgAh3buWqZWrWqh5Csg1ESpUTQu8tMbvnvMpQkWEtWet1XZeSP+N7m2JHio
UKcKkquY8uQd72JcvW6F93i77QLaeHvh6KC3tAwSk+XXfbaz/lfdyJwDoW4UbcGt
mf+iGcagcvvZwYi4kTiFZNVTOYyiqmooIi7D6y8zbUVvLUvKdUud2Iz+ZWMl5Avb
6J0y5sT1+zDa4uD3d9tgYNvVhtYM9lCxK0AW+eLCSC8FaAwIiG+5no4u1gV73pux
kZRICe3EIcfkWuAMZV9WIGTdWDhtCJ6Mudgy+ws0xCU1/cMd0DAJIBb2CrMLu1ac
m35d7dwPi+lVn3Sci7GY7ETOKf40YQ==
=50Lq
-----END PGP SIGNATURE-----


M
M
Maxim Cournoyer wrote on 16 Sep 2022 21:00
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 44944@debbugs.gnu.org)
8735crdu0p.fsf@gmail.com
Hi,

Danny Milosavljevic <dannym@scratchpost.org> writes:

Toggle quote (15 lines)
> The latest guix system reconfigure (of yesterday) left me unable to login into
> my X session. guix system rollback DID NOT fix it.
>
> I would enter my password and it would "try" to login and return right back to
> the gdm login screen.
>
> I've since removed gdm from my OS configuration (because I have to do actual
> *work* on this computer), but I think it would have been enough to just
> chown /var/lib/gdm and rm ~/.xsession-errors (!) in order to make it work
> again.
>
> Does that mean that user ids are non-reproducible?
>
> Why not have user_id = hash(user_name) ? Then they *are* reproducible.

That'd be cool, but how would you implement such a hash, that returns
something fixed between 0 and 1024? That doesn't sound feasible,
although I'm no hash function expert.

Toggle quote (9 lines)
> (I've tried finding the spot where those user accounts are generated/updated
> but so far have been unable to)
>
> Anyway, this is just to record the problem and workaround. I won't do
> further research on this problem on it on this computer.
>
> The "gdm" system account is gone by now because I've removed gdm from the
> OS configuration--and I don't plan on adding it ever again.

I experienced the exact same problem as you. My topmost /var/lib/gdm
directory has the correct permissions, but it contains stale entries
that were created in the past by a different GDM user whose ID is no
longer the same:

Toggle snippet (176 lines)
/var/lib/gdm:
total 616
drwx------ 1 gdm gdm 46 Sep 16 09:09 .
drwxr-xr-x 1 root root 222 May 7 20:40 ..
drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .cache
drwx------ 1 nixbld04 opendht 44 Dec 7 2021 .config
-rw------- 1 955 gdm 1146880 Sep 16 09:09 core
drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 .local

/var/lib/gdm/.cache:
total 0
drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .
drwx------ 1 gdm gdm 46 Sep 16 09:09 ..
drwxr-xr-x 1 nixbld04 opendht 384 Dec 7 2021 fontconfig
drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 ibus
drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 mesa_shader_cache

/var/lib/gdm/.cache/fontconfig:
total 84
drwxr-xr-x 1 nixbld04 opendht 384 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 ..
-rw-r--r-- 1 nixbld04 opendht 18496 Dec 7 2021 23ef510a04af7dd5ac1a2dbd06c4afd1-le64.cache-7
-rw-r--r-- 1 nixbld04 opendht 272 Dec 7 2021 269249ae71e4e445ff7f16f21dcb6de5-le64.cache-7
-rw-r--r-- 1 nixbld04 opendht 256 Dec 7 2021 50fa4f3b9c91fead50cbfcdae3296c45-le64.cache-7
-rw-r--r-- 1 nixbld04 opendht 50584 Dec 7 2021 a927202dec7f348d7a0569dcad9f19a8-le64.cache-7
-rw-r--r-- 1 nixbld04 opendht 200 Dec 7 2021 CACHEDIR.TAG

/var/lib/gdm/.cache/ibus:
total 0
drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 ..
drwxr-xr-x 1 nixbld04 opendht 16 Dec 7 2021 bus

/var/lib/gdm/.cache/ibus/bus:
total 172
drwxr-xr-x 1 nixbld04 opendht 16 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 ..
-rw-r--r-- 1 nixbld04 opendht 173300 Dec 7 2021 registry

/var/lib/gdm/.cache/mesa_shader_cache:
total 36
drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 ..
drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 02
drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 72
drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 88
drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 a3
drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 c4
drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 f9
-rw-r--r-- 1 nixbld04 opendht 1310728 Dec 7 2021 index

/var/lib/gdm/.cache/mesa_shader_cache/02:
total 4
drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 ..
-rw-r--r-- 1 nixbld04 opendht 868 Dec 7 2021 f0edfe0ef96096640b39ff4d2786b503a60a43

/var/lib/gdm/.cache/mesa_shader_cache/72:
total 4
drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 ..
-rw-r--r-- 1 nixbld04 opendht 989 Dec 7 2021 7cd650943c7a3136f424df6a67c7897f922307

/var/lib/gdm/.cache/mesa_shader_cache/88:
total 4
drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 ..
-rw-r--r-- 1 nixbld04 opendht 755 Dec 7 2021 d03ceaeebc55f4b3c972e855775b2c21381b60

/var/lib/gdm/.cache/mesa_shader_cache/a3:
total 4
drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 ..
-rw-r--r-- 1 nixbld04 opendht 1187 Dec 7 2021 2d688084f93805f8921dab8d7a8de5e0f1bc66

/var/lib/gdm/.cache/mesa_shader_cache/c4:
total 4
drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 ..
-rw-r--r-- 1 nixbld04 opendht 523 Dec 7 2021 93ffa46c262472c8d01161a581304a790b71ff

/var/lib/gdm/.cache/mesa_shader_cache/f9:
total 4
drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 ..
-rw-r--r-- 1 nixbld04 opendht 742 Dec 7 2021 14f5ad63c0e5edcc46473d056d0b5e38415f99

/var/lib/gdm/.config:
total 0
drwx------ 1 nixbld04 opendht 44 Dec 7 2021 .
drwx------ 1 gdm gdm 46 Sep 16 09:09 ..
drwx------ 1 nixbld04 opendht 26 Dec 7 2021 gnome-session
drwx------ 1 nixbld04 opendht 6 Dec 7 2021 ibus
drwx------ 1 nixbld04 opendht 500 Dec 7 2021 pulse

/var/lib/gdm/.config/gnome-session:
total 0
drwx------ 1 nixbld04 opendht 26 Dec 7 2021 .
drwx------ 1 nixbld04 opendht 44 Dec 7 2021 ..
drwx------ 1 nixbld04 opendht 0 Dec 7 2021 saved-session

/var/lib/gdm/.config/gnome-session/saved-session:
total 0
drwx------ 1 nixbld04 opendht 0 Dec 7 2021 .
drwx------ 1 nixbld04 opendht 26 Dec 7 2021 ..

/var/lib/gdm/.config/ibus:
total 0
drwx------ 1 nixbld04 opendht 6 Dec 7 2021 .
drwx------ 1 nixbld04 opendht 44 Dec 7 2021 ..
drwx------ 1 nixbld04 opendht 78 Dec 8 2021 bus

/var/lib/gdm/.config/ibus/bus:
total 4
drwx------ 1 nixbld04 opendht 78 Dec 8 2021 .
drwx------ 1 nixbld04 opendht 6 Dec 7 2021 ..
-rw-r--r-- 1 nixbld04 opendht 380 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-unix-0

/var/lib/gdm/.config/pulse:
total 64
drwx------ 1 nixbld04 opendht 500 Dec 7 2021 .
drwx------ 1 nixbld04 opendht 44 Dec 7 2021 ..
-rw------- 1 nixbld04 opendht 36864 Dec 7 2021 c096feaf19ce3a0a450915775e7ec8e3-card-database.tdb
-rw------- 1 nixbld04 opendht 1 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-default-sink
-rw------- 1 nixbld04 opendht 1 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-default-source
-rw------- 1 nixbld04 opendht 12288 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-device-volumes.tdb
-rw------- 1 nixbld04 opendht 696 Dec 7 2021 c096feaf19ce3a0a450915775e7ec8e3-stream-volumes.tdb
-rw------- 1 nixbld04 opendht 256 Dec 7 2021 cookie

/var/lib/gdm/.local:
total 0
drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 .
drwx------ 1 gdm gdm 46 Sep 16 09:09 ..
drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 share

/var/lib/gdm/.local/share:
total 0
drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 ..
drwx------ 1 nixbld04 opendht 0 Dec 7 2021 applications
drwx------ 1 nixbld04 opendht 0 Dec 7 2021 gnome-shell
drwxr-xr-x 1 nixbld04 opendht 82 Dec 7 2021 icc
drwx------ 1 nixbld04 opendht 0 Dec 7 2021 sounds
drwxr-xr-x 1 nixbld04 opendht 96 Dec 8 2021 xorg

/var/lib/gdm/.local/share/applications:
total 0
drwx------ 1 nixbld04 opendht 0 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 ..

/var/lib/gdm/.local/share/gnome-shell:
total 0
drwx------ 1 nixbld04 opendht 0 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 ..

/var/lib/gdm/.local/share/icc:
total 4
drwxr-xr-x 1 nixbld04 opendht 82 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 ..
-rw-r--r-- 1 nixbld04 opendht 1448 Dec 7 2021 edid-5add33c88281761e832ba5f60ec1628e.icc

/var/lib/gdm/.local/share/sounds:
total 0
drwx------ 1 nixbld04 opendht 0 Dec 7 2021 .
drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 ..

/var/lib/gdm/.local/share/xorg:
total 132
drwxr-xr-x 1 nixbld04 opendht 96 Dec 8 2021 .
drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 ..
-rw-r--r-- 1 nixbld04 opendht 52932 Dec 8 2021 Xorg.0.log
-rw-r--r-- 1 nixbld04 opendht 53878 Dec 8 2021 Xorg.0.log.old
-rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log
-rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log.old

We have some logic in %gdm-activation that was supposed to fix that, but
it doesn't kick in, because it has some optimization to not recurse if
the top dir has the correct permissions, and since d429878daf3 the top
directory permissions are always controlled at system activation time
(and this must happen before the gdm activation script runs).

I'll follow-up with a patch that puts /var/lib/gdm on a tmpfs. This
should avoid many pitfalls people have had.

Thanks,

Maxim
M
M
Maxim Cournoyer wrote on 16 Sep 2022 23:03
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 44944-done@debbugs.gnu.org)
87k063jakp.fsf@gmail.com
Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

Toggle quote (18 lines)
> /var/lib/gdm/.local/share/xorg:
> total 132
> drwxr-xr-x 1 nixbld04 opendht 96 Dec 8 2021 .
> drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 ..
> -rw-r--r-- 1 nixbld04 opendht 52932 Dec 8 2021 Xorg.0.log
> -rw-r--r-- 1 nixbld04 opendht 53878 Dec 8 2021 Xorg.0.log.old
> -rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log
> -rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log.old
>
> We have some logic in %gdm-activation that was supposed to fix that, but
> it doesn't kick in, because it has some optimization to not recurse if
> the top dir has the correct permissions, and since d429878daf3 the top
> directory permissions are always controlled at system activation time
> (and this must happen before the gdm activation script runs).
>
> I'll follow-up with a patch that puts /var/lib/gdm on a tmpfs. This
> should avoid many pitfalls people have had.

Pushed as d7e56aebec.

This should fix the issue for good!

Closing.

Maxim
Closed
B
B
bokr wrote on 20 Sep 2022 16:49
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
20220920144957.GA10253@LionPure
Attachment: file
M
M
Maxim Cournoyer wrote on 22 Sep 2022 06:11
(address . bokr@bokr.com)
874jx0avzu.fsf@gmail.com
Hi,

bokr@bokr.com writes:

Toggle quote (32 lines)
> Hi Maxim,
>
> On +2022-09-16 15:00:22 -0400, Maxim Cournoyer wrote:
>> Hi,
>>
>> Danny Milosavljevic <dannym@scratchpost.org> writes:
>>
>> > The latest guix system reconfigure (of yesterday) left me unable to login into
>> > my X session. guix system rollback DID NOT fix it.
>> >
>> > I would enter my password and it would "try" to login and return right back to
>> > the gdm login screen.
>> >
>> > I've since removed gdm from my OS configuration (because I have to do actual
>> > *work* on this computer), but I think it would have been enough to just
>> > chown /var/lib/gdm and rm ~/.xsession-errors (!) in order to make it work
>> > again.
>> >
>> > Does that mean that user ids are non-reproducible?
>> >
>> > Why not have user_id = hash(user_name) ? Then they *are* reproducible.
>>
>> That'd be cool, but how would you implement such a hash, that returns
>> something fixed between 0 and 1024? That doesn't sound feasible,
>> although I'm no hash function expert.
>>
>
> To "return something fixed between 0 and 1024" (1023?) In a context
> with less than 1024 users, couldn't one wrap Danny's "hash(username)"
> with a local function that finds a 0..1023 index into a trusted table
> of hash(username) values represented as string lines?

I'm not sure I follow. If you had some pseudo-code, that might help me
:-).

Toggle quote (4 lines)
> Similar to the idea of representing 32-bit sRGB 16-million-colors+transparency
> with an 8-bit pallette index -- or even a 1-bit index for fg/bg alternates
> to black/white.

I'd need to read more deeply about the topic to understand, but I
welcome mathematicians wizards to devise a cute little function to do
that :-).

Toggle quote (2 lines)
> BTW, for the unlimited-number-of-users case, what sets the 1024 range limit?

It's just a convention for "system" users, e.g. users typically not
having a home directory, and perhaps other traits. It can differ
between distributions. Some information about it here [0].


Thanks,

Maxim
M
M
Maxime Devos wrote on 25 Sep 2022 13:47
(address . 44944@debbugs.gnu.org)
d6954217-2778-f161-87e0-882356ea4ebd@telenet.be
On 16-09-2022 21:00, Maxim Cournoyer wrote:
Toggle quote (3 lines)
> That'd be cool, but how would you implement such a hash, that returns
> something fixed between 0 and 1024? That doesn't sound feasible,
> although I'm no hash function expert.
Remember that any function from X to a finite set Y is a hash function
-- this included very simple ones like e.g. X={1,...,N}, Y={1,...,N},
map every number \(k\) to \(k\).
You can't implement such a hash without hash collisions, due to the
pigeonhole principle, as there are more inputs (user names) that outputs
(numbers between 0 and 1024).
Users can't share uids, so hash collisions are unacceptable.
As collisions are unacceptable (and not just tolerable but disliked),
the 'uniformity' property of some hash functions is unneeded.
If we limit ourselves to only having 1025 users in total, then with some
care there aren't any hash collisions (see proposal by bokr) (*), but
that would place a limit on how many services can be written for Guix.
Of course, an individual system might only have < 1025 users as not all
services are enabled, but then the hash function would depend on the
system in question. However, Guix cannot tell in advance what usernames
will be used in the future, so it would need to gradually build up its
hash function (state!) and remember old 'deleted' users (state!).
But if you have to remember the old users anyway and gradually build up
a hash function, then you might as well simplify things by not going for
a classically "good" hash function but rather a simple table that is
gradually build up (technically a hash function), as I've tried out in
https://issues.guix.gnu.org/36508#21 (currently limited to uids, gid
not yet supported, also largely untested).
(*) Implementation:
(define (hash username)
(define %table
`(("root" . 0)
("foo" . 1)
("bar" . 2)
; <insert entries for all other (system) usernames in Guix here>
[...]))
(or (assoc-ref %table username)
(error "doesn't exist")))
Greetings,
Maxime.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
M
M
Maxim Cournoyer wrote on 27 Sep 2022 02:12
(name . Maxime Devos)(address . maximedevos@telenet.be)
87tu4ty8sw.fsf@gmail.com
Hello,

Maxime Devos <maximedevos@telenet.be> writes:

Toggle quote (9 lines)
> On 16-09-2022 21:00, Maxim Cournoyer wrote:
>> That'd be cool, but how would you implement such a hash, that returns
>> something fixed between 0 and 1024? That doesn't sound feasible,
>> although I'm no hash function expert.
>
> Remember that any function from X to a finite set Y is a hash function
> -- this included very simple ones like e.g. X={1,...,N}, Y={1,...,N},
> map every number \(k\) to \(k\).

[...]

Toggle quote (19 lines)
> But if you have to remember the old users anyway and gradually build
> up a hash function, then you might as well simplify things by not
> going for a classically "good" hash function but rather a simple table
> that is gradually build up (technically a hash function), as I've
> tried out in <https://issues.guix.gnu.org/36508#21> (currently limited
> to uids, gid not yet supported, also largely untested).
>
> (*) Implementation:
>
> (define (hash username)
> (define %table
> `(("root" . 0)
> ("foo" . 1)
> ("bar" . 2)
> ; <insert entries for all other (system) usernames in Guix here>
> [...]))
> (or (assoc-ref %table username)
> (error "doesn't exist")))

Thanks for explaining. Thinking some more about it, it seems having
such a function would be of limited value after all: it'd only be useful
to avoid confusion about stale files ownership by avoiding to reuse any
user id used in the present or past; it wouldn't avoid having stale
files with the wrong ownership.

So the solution seems to instead be extra careful with removing as much
state as we can, and checking things in activation scripts. For GDM for
example I was able to put the /var/lib/gdm directory on a tmpfs which
gets reset on every reboot, which should help with this and other (stale
cache files) problem its service had.

Thanks,

Maxim
?
Your comment

This issue is archived.

To comment on this conversation send an email to 44944@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 44944
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch