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.

  • A_norny_mousse
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    19 hours ago

    $ 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.

    • xavier666@lemm.eeOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      4 hours 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
        1
        ·
        edit-2
        2 hours 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

        • xavier666@lemm.eeOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          27 minutes ago

          user-IDs (prefixed with ‘#’)

          And I thought it just meant a comment.

          Thanks for this, I had no idea.

      • A_norny_mousse
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        3 hours 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.