Can't start `pkexec swhkd`, XDG_CONFIG_HOME not found

[fritzrehde]

I have started swhks & in the background and am now trying to run pkexec swhkd, but I receive all of these errors:

[2023-04-08T14:11:59Z ERROR swhkd] XDG_RUNTIME_DIR has not been set.
[2023-04-08T14:11:59Z WARN  swhkd] Running swhkd as root!
[2023-04-08T14:11:59Z ERROR swhkd] XDG_CONFIG_HOME has not been set.
[2023-04-08T14:11:59Z ERROR swhkd] Config Error: Config file not found.

I am running on Arch Linux using river.
If I type in echo $XDG_CONFIG_HOME, I get the equivalent of $HOME/.config, so I am not sure why swhkd can't recognize it. Any ideas?

[loiccoyle]

I think it's because it's running as the root user. You can specify the config file path yourself using the -c option.

[fritzrehde]

Well, it's only running as root user because apparently it needs pkexec, which runs as root user if I understand correctly.

[Shinyzenith]

man swhkd lists the default path of config file lookup. Do you have a config file created at said path?

[heyzec]

I may be missing something, I think it then does not make sense for swhkd to be looking for the config file in $XDG_CONFIG_HOME/swhkd/swhkdrc since it is expected to be running as root via pkexec, and $XDG_CONFIG_HOME is meant to be user-specific.

[ItsProfessional]

The first problem is that swhkd tries to use the config in your ~/.config directory that's stored in the XDG_CONFIG_HOME environment variable. However since pkexec doesn't pass-through all environment variables (such as XDG_CONFIG_HOME), swhkd falls back to a hardcoded path that is /etc/swhkd/swhkdrc

The second problem is that swhkd errors if the config file doesn't exist at the path it decides on.
A workaround is to create that file, which will fix the errors, but it'll still warn you that XDG_CONFIG_HOME is not set, but there'll be no errors and it'll work fine.

You can also symlink your personal config file (i.e. ~/.config/swhkd/swhkdrc) to the hardcoded /etc/swhkd/swhkdrc, if you want to feel that this problem didn't exist in the first place

sudo ln -sf ~/.config/swhkd/swhkdrc /etc/swhkd

[Radical-Egg]

Hi, I am also having this issue using Fedora39

I think that the drop_privileges function is not working as expected when called here.

Expected Behavior:

When I run the program with XDG_CONFIG_HOME set my config file should be loaded.

Actual:

egg@astro-egg:~/code/swhkd$ ./target/release/swhks & pkexec ./target/release/swhkd
[1] 80270
[2024-01-08T00:26:34Z ERROR swhkd] XDG_RUNTIME_DIR has not been set.
[2024-01-08T00:26:34Z WARN  swhkd] Running swhkd as root!
[2024-01-08T00:26:34Z ERROR swhkd] XDG_CONFIG_HOME has not been set.
[2024-01-08T00:26:35Z ERROR swhkd] XDG_RUNTIME_DIR has not been set.
[2024-01-08T00:26:35Z ERROR swhkd] Could not open evdev device at /dev/input/mouse1: Inappropriate ioctl for device (os error 25)
^C[2024-01-08T00:26:41Z WARN  swhkd] Received SIGINT signal, exiting...

I tried to add the following right after drop_privileges to inspect the environment variables

    let load_config = || {
        // Drop privileges to the invoking user.
        perms::drop_privileges(invoking_uid);

        let env_vars: Vec<(String, String)> = env::vars().collect();

        // Print the environment variables
        for (key, value) in env_vars {
            println!("{}: {}", key, value);
        }
....

I expected that this would show me my users environment variables but I got the root user instead.

egg@astro-egg:~/code/swhkd$ ./target/release/swhks & pkexec ./target/release/swhkd
[1] 80966
[2024-01-08T00:29:29Z ERROR swhkd] XDG_RUNTIME_DIR has not been set.
[2024-01-08T00:29:29Z WARN  swhkd] Running swhkd as root!
SHELL: /bin/bash
LANG: en_US.UTF-8
TERM: xterm-256color
COLORTERM: truecolor
PATH: /usr/sbin:/usr/bin:/sbin:/bin:/root/bin
LOGNAME: root
USER: root
HOME: /root
PKEXEC_UID: 1000
RUST_LOG: swhkd=warn
[2024-01-08T00:29:29Z ERROR swhkd] XDG_CONFIG_HOME has not been set.
[2024-01-08T00:29:30Z ERROR swhkd] XDG_RUNTIME_DIR has not been set.
[2024-01-08T00:29:30Z ERROR swhkd] Could not open evdev device at /dev/input/mouse1: Inappropriate ioctl for device (os error 25)
^C[2024-01-08T00:29:32Z WARN  swhkd] Received SIGINT signal, exiting...

Is it the case that after drop_privs is called, we should be seeing the effective user environment variables until raise_privileges() is called?

[Shinyzenith]

This is definitely an issue with our privilege system but #201 (comment) shows how to work around it. We are actively working on improving this experience for users via our gsoc program.

[Shinyzenith]

@Radical-Egg That definitely seems like a bug in our priv esc model.