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.

That would work.

I’m not sure what could be in (or missing from) your environment that would break sudo, but it’s a place to check at least.

This goes a little beyond me because I have no idea how gdm would differentiate Xorg or wayland sessions.

Look into the session files themselves (.desktop) - they have an Exec= line. Then see if that’s maybe just a shell wrapper around something else, e.g.: file /usr/bin/sway and see what it does.

That’s all I have.

(Why are there % signs)

Good question, here’s the explanation man sudoers offers:

The definitions of what constitutes a valid alias member follow.

       User_List ::= User |
                     User ',' User_List

       User ::= '!'* user name |
                '!'* #user-ID |
                '!'* %group |
                '!'* %#group-ID |
                '!'* +netgroup |
                '!'* %:nonunix_group |
                '!'* %:#nonunix_gid |
                '!'* User_Alias

       A User_List is made up of one or more user names, user-IDs
       (prefixed with ‘#’), system group names and IDs (prefixed with ‘%’
       and ‘%#’ respectively), netgroups (prefixed with ‘+’), non-Unix
       group names and IDs (prefixed with ‘%:’ and ‘%:#’ respectively),
       and User_Aliases. Each list item may be prefixed with zero or more
       ‘!’ operators.  An odd number of ‘!’ operators negate the value of
       the item; an even number just cancel each other out.  User
       netgroups are matched using the user and domain members only; the
       host member is not used when matching.

TL;DR % lets the system know the following word is a group name, instead of a username

In that case Ubuntu DOES things differently. And weirdly imho, there’s no reason for the normal user to be in the root group since they still need privilege escalation to edit system files.

If you use visudo to edit /etc/sudoers you don’t have to worry about the syntax.

FWIW, this is what my perfectly healthy system looks like:

$ sudo grep -vE '^[[:space:]]*#|^[[:space:]]*$' /etc/sudoers
Defaults	env_reset
Defaults	mail_badpass
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults	use_pty
root	ALL=(ALL:ALL) ALL
%sudo	ALL=(ALL:ALL) ALL
@includedir /etc/sudoers.d

$ groups
a_norny_mousse adm dialout fax cdrom floppy tape sudo audio dip video plugdev netdev bluetooth lpadmin scanner

You will notice that my user is in the sudo group; this is enough to give them admin rights as per sudoers.

You run it and then reboot. If that doesn’t fix it, then it didn’t fix it :\