bug#73680: privileged-programs: cant set setuid/setgid to new accounts/groups

[Dariqq <dariqq@posteo.net>]

I downloaded the latest iso 
(https://ci.guix.gnu.org/build/6060923/details from yesterday) and tried 
to install opensmtpd in there.

After the reconfigure i got the 'failed to privilege <binary>: Success' 
warning but upon reboot things were working.

I think I know what is happening now:

The *first* time we try to privilege something it fails because the 
group does not yet exist. After a reboot it is succeeeding because it is 
using the group info from the previous boot, because that has not been 
recreated yet.

This seems to work for groups because the getgrnam error "group does not 
exist" is a 'system-error being caught by the exception handler, while 
the getpwnam-error "user does not exist" is a 'misc-error instead, 
causing a backtrace which aborts further activation scripts (that would 
create the user)

As a simple workaround we could catch the getpwnam error too but this is 
not really solving anything and relies on previous state which might be 
incorrect. This is also really fragile.


Another idea would be to run the account+user creating scripts as early 
as possible. Or as a more thorough solution model the dependency on 
users/groups directly to enforce the ordering (might be problematic 
because some activation scripts also requrie a user/group to set 
permissions which would make the extension graph not acyclic (accounts 
-> activation -> accounts). Maybe this is doable with a more minimal 
accounts service that only knows about users/group names?

I am surprised this has not been causing issues earlier as also a lot of 
direct activation-extensions set ownership on directories (that this 
works seems like a lucky coincidence in how 
service-extension/service-folding works rather than a design consideration).