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.

  • xavier666@lemm.eeOP
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 day ago

    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?

    • BaumGeist@lemmy.ml
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      1 day ago

      (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

    • A_norny_mousse@feddit.org
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 day ago

      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.