Fix permission groups

[andycandy-dev]

Problem

Terminal emulators and other applications launched via swhkd were missing supplementary groups, causing permission issues. This occurred when the user's GID differs from their UID (e.g., on NixOS and some enterprise Linux distributions).

The root cause was that the code only called setgid() and setuid() without calling initgroups() to set supplementary groups. Additionally, it incorrectly assumed UID equals GID, passing the UID value to setgid().

Solution

This PR properly sets user privileges when spawning commands by:

1. Looking up the User structure to get the actual GID (instead of assuming UID = GID)
2. Using Command::uid() and Command::gid() to run child processes with correct privileges
3. Letting the OS handle initgroups() automatically when setting uid/gid on the child process

Changes:

1. Import std::os::unix::process::CommandExt for .uid() and .gid() methods
2. Look up the User structure to get the actual GID
3. Set .uid() and .gid() on the Command builder instead of calling setuid()/setgid() in the parent process

Related

This follows the same approach used in commit 6b1e62e to fix CVE-2022-27814 and CVE-2022-27819, but applies it to command execution rather than just config file loading.

fixes #320

Testing

Tested on systems where UID ≠ GID (nixOs). Verified that spawned processes now have all supplementary groups correctly set.

[heyzec]

This PR works in theory, but seems to crash on the second keypress.

thread 'tokio-runtime-worker' panicked at swhkd/src/daemon.rs:207:18:
Failed to set supplementary groups for UID 1000: EPERM
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
zsh: IOT instruction  sudo swhkd

When handling the first keypress, setuid will drop root permissions. Hence, on the second keypress, it no longer has permissions to set UID, GID and groups. This seems to be a design flaw in the original implementation of the security model, since threads share UID, GID and groups.

[andycandy-dev]

@heyzec yes, addressed in the 455d646
no longer dropping perms on the main thread, setting correctly when invoking commands.

[heyzec]

Yeah. it looks great now. Thanks!

[Shinyzenith]

Hey @heyzec Does this pr work on your end? I'll merge it then