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.
Can you provide output of
which sway,sway --version,file $(which sway)andls -l $(which sway)?Also, can you run
id, after logging in w/o gdm on the console, and then again after starting sway?The fact that your group membership changes even when starting sway from a tty, as mentioned in some other comment, is super weird. I believe newer versions of sway should not mess with this.
AFAIK some versions ago, sway used to be (or at least could be) a setuid root binary (something something needed root privileges for some reason to do with h/w access), but no longer. Back then it looks like it did mess with group membership etc.
I have this hunch, that maybe your binary has the setgid bit set for some reason (due to, perhaps, an oversight made by the packager, because in the old package that was needed).
$ which sway /usr/bin/sway $ sway --version sway version 1.9 $ file $(which sway) /usr/bin/sway: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=70fe358f7e410f618ad8a9ce0e573ed6826b2e75, for GNU/Linux 3.2.0, stripped $ ls -l $(which sway) -rwxr-xr-x 1 root root 600352 Apr 1 2024 /usr/bin/swayidpre and post loginuid=1000(xavier666) gid=1000(xavier666) groups=1000(xavier666),0(root) --------------- uid=1000(xavier666) gid=1000(xavier666) groups=1000(xavier666),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),120(lpadmin),132(lxd),133(sambashare)A funny thing; I think this has nothing to do with gdm. I have gdm disabled now and launching sway directly from the terminal and the issue still persists.
The problem goes away (
xavier666becomes part ofsudolike expected) when I typeexec su - xavier666for that terminal session only. If I open a new terminal, it problem reappears. I’ll just in case check if zsh/omyzsh is doing something funny.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 -loutput)?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.
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/swhkdSince 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.
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:
- Gets started as root by the kernel because of setuid bit and root ownership of the binary.
- Opens
/dev/input/event*files to read keyboard events. This is presumably what it wants root for. - 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.
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.
Hmm let’s try to isolate the bug to know if it’s sway or gdm messing up:
Try to disable gdm:
sudo systemctl disable gdm.serviceLogout/restart. You should be at the TTY, enter username and password to login. Then simply type
swayNow, test your sudo commands within this sway session. Do you still get the same bug?
Great suggestion. I tried this method just now.
Unfortunately, I’m still getting the same bug.
The main difference between the two sessions is the output of the
groupscommandIn pure tty
$ groups xavier666 adm cdrom sudo dip plugdev lpadmin lxd sambashareThe moment I enter into sway from inside the tty
$ groups xavier666 rootI found something interesting, thanks to my friend
- I removed the fix mentioned above. Now user does not have
sudoaccess inside sway - I ran the command
exec su - xavier666. It asked for my user password and the command was accepted. - My
groupsoutput looks normal (xavier666is now part ofsudo) and my permissions are fine - However, the problem reappears after a reboot
It is as if this user is an imposter with incorrect privileges 📮
It is as if this user is an imposter with incorrect privileges
No, this rather points to sway/wayland.
Once again:
- you will need to figure out how wayland sessions in general start up on your system
file /usr/bin/swayif that command says it’s some sort of text/scii/script, open it in an editor and see what it does. It might give you first clues.
- I removed the fix mentioned above. Now user does not have
From my experience a user account usually needs to be in the “wheel” group to elevate privileges through sudo. So try that.
Or in the
sudogroup. It differs.
Can you compare
groupsoutput under both sessions?Specifically, if you don’t show membership of sudo in your Sway session, try this
loginctl enable-linger lazarusInisde i3 WITHOUT FIX
$ groups xavier666 adm cdrom sudo dip plugdev lpadmin lxd sambashare $ groups xavier666 xavier666 : xavier666 adm cdrom sudo dip plugdev lpadmin lxd sambashareInside sway WITH/WITHOUT FIX
$ groups xavier666 root $ groups xavier666 xavier666 : xavier666 adm cdrom sudo dip plugdev lpadmin lxd sambasharePS: I corrected the username, it should be
xavier666. I corrected the main post.$ groups
xavier666 root
Sorry what? As what user are you executing all these ‘groups’ commands? Unless Ubuntu does things significantly differently from Arch and Debian, there’s something very fishy going on here. The “normal” user should not be in the root group, and root should not be in the normal user’s group.
Have you done other things beside the “fix” you mentioned?
That “fix” from your op, btw, looks totally valid to me.
As what user are you executing all these ‘groups’ commands?
I’m using my default user (
xavier666)The “normal” user should not be in the root group, and root should not be in the normal user’s group.
I just made the user a root user/system administrator during the Ubuntu installation process, which is very standard.
Have you done other things beside the “fix” you mentioned?
AFAIK, I haven’t done any changes. This is a single user system. I checked the contents of
/etc/sudoersand these are the only other lines of significance. I didn’t change them (Why are theresigns?)# User privilege specification root ALL=(ALL:ALL) ALL xavier666 ALL=(ALL:ALL) ALL # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALLThat “fix” from your op, btw, looks totally valid to me.
It’s working fine also. However, I believe in “don’t touch what ain’t broke” and “why isn’t it documented?”
However, in my installations I have never touched the sudoer file to make the ONLY user part of
sudogroup post install. Either I’m dumb or I’m launching sway/wayland with improper permissions.I also can’t find anything on the arch wiki which deals with this.
Why isn’t the same problem happening on i3?
(Why are there
signs)Good question, here’s the explanation
man sudoersoffers: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!lemmysilver
user-IDs (prefixed with ‘#’)
And I thought it just meant a comment.
Thanks for this, I had no idea.
No problem, I love when people show curiosity, and I’m happy to help where I can
