Hello fellow lemmings

I am a long-time i3 user and have decided to switch to Sway. I have encountered a weird error which has left me utterly bamboozled.

I am using Ubuntu 24.04 which has gone from 20.04 -> 22.04 -> 24.04. It has Ubuntu-Gnome, i3 and Sway currently installed.

The issue

The error that I’m facing is when I’m using Sway, I simply don’t have sudo access.

This is what the error looks like

$ sudo visudo
[sudo] password for xavier666:
Sorry, user xavier666 is not allowed to execute '/usr/sbin/visudo' as root on <HOSTNAME>.

When I switch back to i3, my permissions are fine for the same user. I have not done any crazy modifications to the sudoer’s file as far as I can remember.

PS: I have added a command to no-sudo xavier666 ALL = NOPASSWD: /usr/bin/brightnessctl

The “fix”

I temporarily solved it by adding xavier666 ALL=(ALL:ALL) ALL to the sudoer’s file.

IMO, I think this should not be required. I don’t remember ever adding the default user to the file for all the installations that I have done. (But this is the first time I’ve installed Sway)

Logs/Outputs

Running sudo -l without the fix (on Sway)

Matching Defaults entries for xavier666 on <HOSTNAME>:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin,
    use_pty

User xavier666 may run the following commands on <HOSTNAME>:
    (root) NOPASSWD: /usr/bin/brightnessctl

When I run the same command on i3, i get this (ALL : ALL) ALL extra line in the output. And when I run sudo -l with my fix on Sway, (ALL : ALL) ALL is present and the permission issue is fixed.

What is causing Sway to remove the root permission for the user?

Note: I’m just asking for the standard sudo behaviour. I’m not trying to run GUI applications as root.

Edit:

The issue was caused by swhkd. It was installed as a setuid binary (as instructed by the developer of the project). Once I switched back to sway’s default keybinds and disabled swhkd, the permissions were back to normal. I removed my previous “fix” in the sudoers list and I still have sudo access.

Thanks a lot everyone and specially @gnuhaut@lemmy.ml for pointing me in the right direction.

  • @gnuhaut@lemmy.ml
    1•1 day ago

    Yeah so this does not confirm my hunch, and I don’t think sway is changing your group membership. Version 1.9 does not allow sway to be installed setuid root, and it isn’t, as confirmed by the ls output.

    So it must be something else. It could be anything between the login shell in the console and the shell started with the messed up groups. What’s weird is that in order to change group membership, you would need root permissions (technically you only need CAP_SETGID, but why would you have that?). I think there are really only two ways to do that: Run a binary that has the setuid bit (like e.g. sudo) or CAP_SETGID, or talk to some process (e.g. a daemon like systemd) that is already running as root, and ask it to do that for you.

    I cannot imagine why anything between the login shell -> sway -> ??? -> zsh would be either setuid root, or have any reason or permission to change groups in any way. So that’s really weird and interesting.

    How do you open the shell inside sway? Keyboard binding from sway config? Launcher? Which terminal? Do any of the involved programs have setuid root bit set (looks like rws instead of x in ls -l output)?

    About zsh: I mean I guess in theory one could change groups in the zsh configuration if you had the permissions (which you shouldn’t have), but I cannot think of any reasonable explanation why anybody would want do that.

    • @xavier666@lemm.eeOPEnglish
      2•1 day ago

      How do you open the shell inside sway? Keyboard binding from sway config? Launcher? Which terminal? Do any of the involved programs have setuid root bit set (looks like rws instead of x in ls -l output)?

      I think you may have just pointed me to the correct direction.

      My keybinds setup is a bit weird. I’m using swhkd instead of sway’s built in keybinds. swhkd is a setuid binary (https://github.com/waycrate/swhkd?tab=readme-ov-file#running) which might be causing the issue. I’ll quickly disable swhkd and check if the issue is resolved. Will keep you posted.

    • @xavier666@lemm.eeOPEnglish
      1•24 hours ago

      Issue resolved!

      It was swhkd. Thank you very much for your insight and extremely detailed response!

      $ ls -l $(which swhkd)
-rwsr-xr-x 1 root root 2583192 Mar 10 17:16 /usr/bin/swhkd

      Since we know what’s causing it, can you make a “guesstimate” of what it’s doing? Why are other applications are getting infected by it? And why is a keybind manager affecting permissions?

      I will raise an issue on their github. The project is already looking for maintainers.

      • @gnuhaut@lemmy.ml
        2•22 hours ago

        Yeah no problem. This is a bug inside swhkd.

        My guess is, swhkd is setuid root so it can open /dev/input/event* files, which are the keyboard devices.

        These days, sway (or any other wayland compositor) gets access to keyboard events by talking to logind (or elogind or seatd if you don’t have systemd). But logind, I think, will only allow one program (e.g. sway) access to keyboard events at a time, so as not to allow keyloggers to be implemented.

        This is also why sway used to support running setuid root, because that way it can access the devices without logind.

        I think what swhkd does is:

        1. Gets started as root by the kernel because of setuid bit and root ownership of the binary.
        2. Opens /dev/input/event* files to read keyboard events. This is presumably what it wants root for.
        3. Waits for keyboard events by reading the open file descriptor(s). When it finds one of the configured shortcuts, it calls fork(2) (to duplicate itself) followed by setuid(2) (in the forked process) to drop privileges and run as a normal user, and then execve(2) to execute your command.

        The problem is that it messes up somewhere and doesn’t set the correct group membership. It would probably need to call initgroups(3) to correct this, I think.

        I will also say, because that page says this is perfectly safe, that maybe the author(s) don’t know what they’re talking about, because frankly the fact you were a member of the root group, even though your user isn’t supposed to be, is already concerning and a minor privilege escalation. Setuid root binaries were an endless source of privilege escalation vulnerabilities in the past.

        But then again, a typical sudo-enabled setup is already like you’re an admin user, so you’re already pretty much f-ed if your user account gets compromised. So whatever I guess.

        You may want to report this bug to them.