* bug#44944: Unable to log into X session via gdm
2022-09-16 19:00 ` Maxim Cournoyer
@ 2022-09-16 21:03 ` Maxim Cournoyer
2022-09-20 14:49 ` bokr
2022-09-25 11:47 ` Maxime Devos
2 siblings, 0 replies; 9+ messages in thread
From: Maxim Cournoyer @ 2022-09-16 21:03 UTC (permalink / raw)
To: Danny Milosavljevic; +Cc: 44944-done
Hi,
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
[...]
> /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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#44944: Unable to log into X session via gdm
2022-09-16 19:00 ` Maxim Cournoyer
2022-09-16 21:03 ` Maxim Cournoyer
@ 2022-09-20 14:49 ` bokr
2022-09-22 4:11 ` Maxim Cournoyer
2022-09-25 11:47 ` Maxime Devos
2 siblings, 1 reply; 9+ messages in thread
From: bokr @ 2022-09-20 14:49 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: Danny Milosavljevic, 44944
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?
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.
BTW, for the unlimited-number-of-users case, what sets the 1024 range limit?
> > (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:
>
> --8<---------------cut here---------------start------------->8---
> /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
> --8<---------------cut here---------------end--------------->8---
>
> 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
>
>
>
PS. WDYT..
(If there isn't a tool already available that'd make it easy to use
the one-liners pro devs can concoct off the top of their heads :)
..of having a package that would install a script
to output a reminder of stale-cache-items-in-general?
It could e.g. be triggered on login by a user
more than <some configured time> since last login,
with output similar to guile's.
As a model I notice guile seems to notice stale cached .go files,
as demoed by:
--8<---------------cut here---------------start------------->8---
$ cat is-this-stale_q
#!/usr/bin/env -S guile -s
!#
(display "Test 1: is this stale??\n")
--8<---------------cut here---------------end--------------->8---
--8<---------------cut here---------------start------------->8---
$ ./is-this-stale_q
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/bokr/BS/bs20220919_2206/./is-this-stale_q
;;; compiled /home/bokr/.cache/guile/ccache/2.2-LE-8-3.A/home/bokr/BS/bs20220919_2206/is-this-stale_q.go
Test 1: is this stale??
--8<---------------cut here---------------end--------------->8---
--8<---------------cut here---------------start------------->8---
$ ./is-this-stale_q
Test 1: is this stale??
--8<---------------cut here---------------end--------------->8---
$ fg # back to emacs for mod: s/Test 1/Test 2/
emacs -nw is-this-stale_q
--8<---------------cut here---------------start------------->8---
$ ./is-this-stale_q
;;; note: source file /home/bokr/BS/bs20220919_2206/./is-this-stale_q
;;; newer than compiled /home/bokr/.cache/guile/ccache/2.2-LE-8-3.A/home/bokr/BS/bs20220919_2206/is-this-stale_q.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/bokr/BS/bs20220919_2206/./is-this-stale_q
;;; compiled /home/bokr/.cache/guile/ccache/2.2-LE-8-3.A/home/bokr/BS/bs20220919_2206/is-this-stale_q.go
Test 2: is this stale??
--8<---------------cut here---------------end--------------->8---
--8<---------------cut here---------------start------------->8---
$ ./is-this-stale_q
Test 2: is this stale??
--8<---------------cut here---------------end--------------->8---
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#44944: Unable to log into X session via gdm
2022-09-20 14:49 ` bokr
@ 2022-09-22 4:11 ` Maxim Cournoyer
0 siblings, 0 replies; 9+ messages in thread
From: Maxim Cournoyer @ 2022-09-22 4:11 UTC (permalink / raw)
To: bokr; +Cc: Danny Milosavljevic, 44944
Hi,
bokr@bokr.com writes:
> 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
:-).
> 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 :-).
> 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].
[0] https://unix.stackexchange.com/a/80279/82353
Thanks,
Maxim
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#44944: Unable to log into X session via gdm
2022-09-16 19:00 ` Maxim Cournoyer
2022-09-16 21:03 ` Maxim Cournoyer
2022-09-20 14:49 ` bokr
@ 2022-09-25 11:47 ` Maxime Devos
2022-09-27 0:12 ` Maxim Cournoyer
2 siblings, 1 reply; 9+ messages in thread
From: Maxime Devos @ 2022-09-25 11:47 UTC (permalink / raw)
To: Maxim Cournoyer, Danny Milosavljevic; +Cc: 44944
[-- Attachment #1.1.1: Type: text/plain, Size: 2097 bytes --]
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\).
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 #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#44944: Unable to log into X session via gdm
2022-09-25 11:47 ` Maxime Devos
@ 2022-09-27 0:12 ` Maxim Cournoyer
0 siblings, 0 replies; 9+ messages in thread
From: Maxim Cournoyer @ 2022-09-27 0:12 UTC (permalink / raw)
To: Maxime Devos; +Cc: Danny Milosavljevic, 44944
Hello,
Maxime Devos <maximedevos@telenet.be> writes:
> 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\).
[...]
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread