Linux groups are not set correctly after new security model

[heyzec]

Version Information:

• Distribution: NixOS
• swhkd version: Simple-Wayland-HotKey-Daemon 1.3.0-dev, built off c5c4071

Describe the bug:
In terminal emulators launched via swhkd, any command with sudo will not work, with error <user> is not in the sudoers file., the groups of the process may be missing. This occurs when the user's GID is not the same value as the UID.

To Reproduce:

1. Create a minimal config file:

super + enter
    alacritty

2. Start swhkd

swhks & sudo swhkd

3. Launch the terminal, e.g. Super + Enter

4. Run a command with sudo, e.g. sudo echo hi
4. Run the id command to see groups of the current process.

Additional information:
I'm very confused by this bug as environment variables like $USER, $UID, $LOGNAME, $HOME all seem normal.

The cause is from here

swhkd/swhkd/src/daemon.rs

Line 198 in c5c4071

setgid(Gid::from_raw(invoking_uid)).unwrap();

While for most Linux distributions UID = GID (e.g. Ubuntu, Arch if I'm not wrong), this is not a universal rule.

We need to call initgroups() to set the supplementary groups of the user as well.

[Borroot]

I also have this issue on Arch Linux using the same version of swhkd. Using id I found that indeed the UID and GID are equal, however spawned shells do not setup the groups correctly. My user is in the wheel group, but in a spawned shell this is not the case.

[heyzec]

If swhks now acts as a beacon that tells swhkd about what environment to run commands within, can it also send GID and supplementary groups information? Not sure if there are security implications.

@Shinyzenith What do you think?