2w ago

Weird root permission issue on Sway which is not present in i3

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.

42 comments

Can you compare groups output under both sessions?
Specifically, if you don't show membership of sudo in your Sway session, try this
loginctl enable-linger lazarus
- Inisde i3 WITHOUT FIX
  
  $ groups xavier666 adm cdrom sudo dip plugdev lpadmin lxd sambashare $ groups xavier666 xavier666 : xavier666 adm cdrom sudo dip plugdev lpadmin lxd sambashare
  Inside sway WITH/WITHOUT FIX
  
  $ groups xavier666 root $ groups xavier666 xavier666 : xavier666 adm cdrom sudo dip plugdev lpadmin lxd sambashare
  PS: 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/sudoers and these are the only other lines of significance. I didn't change them (Why are there % signs?)
  
  # 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) ALL
  That “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 sudo group 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 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
  
  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
  
  !lemmysilver
  
  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.
  
  The output of the above command is nearly the same for me.
  Even though I have manually added myself to /etc/sudoers file, my groups output is very weird. It's just xavier666 root
  Kind of stumped here.
  
  Even though I have manually added myself to /etc/sudoers file, my groups output is very weird.
  One has nothing to do with the other.
  
  I was experimenting. This might be helpful (https://lemm.ee/post/62662283/20097388)
  
  Try enable-linger. As I understand it, the issue is related to the way Sway handles Wayland sockets, and enable-linger kicks things off before Sway is involved.
  
  I'm unsure how to use the command. I added it to the main Sway config file, which means it's executed whenever Sway starts (Post login).
  However, it didn't make any difference. I also ran it manually
  
  $ loginctl enable-linger xavier666 $ sudo visudo [sudo] password for xavier666: Sorry, user xavier666 is not allowed to execute '/usr/sbin/visudo' as root on <HOSTNAME>.
  
  You run it and then reboot. If that doesn't fix it, then it didn't fix it :\
  
  Yeah, I ran it and rebooted it. But no change :(
  I'll do it once more just in case.

42 comments