Weird root permission issue on Sway which is not present in i3
from xavier666@lemm.ee to linux@lemmy.ml on 29 Apr 06:16
https://lemm.ee/post/62662283

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.

#linux

threaded - newest

A_norny_mousse@feddit.org on 29 Apr 06:52 next collapse

This likely has nothing to do with sway but with the way the sway session is started, as opposed to the i3 session.
We need more info on this.

Isn’t i3 Xorg only, and sway wayland only? That would mean the whole graphical server has also changed.

xavier666@lemm.ee on 29 Apr 07:07 collapse

but with the way the sway session is started, as opposed to the i3 session. We need more info on this.

I’m using gdm to start sway. I’m using the laptop’s built-in fingerprint scanner to unlock (Not sure if it matters). I saved the fingerprint in the Gnome session long back.

gdm probably looks inside /usr/share/wayland-sessions and finds sway.desktop and uses it to launch Sway.

I’ve tried to keep things as vanilla as possible.

Isn’t i3 Xorg only, and sway wayland only?

Correct.

Maybe wayland is launched using restrictive set of permissions.

A_norny_mousse@feddit.org on 29 Apr 07:51 next collapse

You’re going to have to look at how that process works on Ubuntu and how it differes from Xorg session start.

gdm probably looks inside /usr/share/wayland-sessions and finds sway.desktop and uses it to launch Sway.

FWIW, these are all text files. Look at them.

Sorry, I have to go now. More tonight, if you want.

xavier666@lemm.ee on 29 Apr 08:01 collapse

these are all text files

Yeah, it just calls the executable mentioned in the .desktop file (/usr/bin/sway). It should not be a GDM, issue, right?

I also checked that I don’t have seatd installed, which is a “minimal user, seat and session management daemon” mentioned in arch wiki (wiki.archlinux.org/title/Sway). Could it be related?

Sorry, I have to go now. More tonight, if you want.

No hurry, the fix I am using is not causing issue. I just want to know why this is happening. This is a fun research problem.

PS: I checked Google and I didn’t find anyone who has faced the same issue.

yardy_sardley@lemmy.ca on 29 Apr 11:03 next collapse

One big difference is that sway doesn’t run as a login process (and neither does gdm), meaning none of your .profile files are getting sourced. Check how your environment variables differ between i3 and sway and see if that might be the issue.

xavier666@lemm.ee on 30 Apr 06:59 collapse

Check how your environment variables differ between i3 and sway and see if that might be the issue

Just running set for each session and then diff should be enough, right?

yardy_sardley@lemmy.ca on 30 Apr 17:47 collapse

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.

A_norny_mousse@feddit.org on 29 Apr 17:34 next collapse

gdm probably looks inside /usr/share/wayland-sessions and finds sway.desktop and uses it to launch Sway.

And how did you use to start i3?

xavier666@lemm.ee on 30 Apr 06:58 collapse

Just the way I launch sway; via gdm.

A_norny_mousse@feddit.org on 30 Apr 07:29 collapse

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.

xavier666@lemm.ee on 30 Apr 10:19 collapse

For i3, the desktop file is like this (present in /usr/share/xsessions)

[Desktop Entry]
Name=i3
Comment=improved dynamic tiling window manager
Exec=i3
TryExec=i3
Type=Application
X-LightDM-DesktopName=i3
DesktopNames=i3
Keywords=tiling;wm;windowmanager;window;manager;

And sway (present in /usr/share/wayland-sessions)

[Desktop Entry]
Version=1.0
Name=Sway
Comment=An i3-compatible Wayland compositor
Exec=/usr/bin/sway
Type=Application
DesktopNames=sway

Gdm probably sums up all the DE from both the wayland and x11 sessions.

There are some files & directories in /etc/gdm3 but I’m too lazy to go through all of them

Init       PostSession  Prime     config-error-dialog.sh  greeter.dconf-defaults
PostLogin  PreSession   PrimeOff  custom.conf             Xsession

Thanks for your help.

A_norny_mousse@feddit.org on 30 Apr 14:53 collapse

but I’m too lazy to go through all of them

OK. But you did want to solve this just because you’re interested?

phantomwise@lemmy.ml on 30 Apr 18:29 collapse

Does the same issue also happen if you launch sway from the tty and not from gdm ?

I’ve never used gdm but it probably allow you to open a tty with Ctrl+Alt+F3, then log in and type sway.

xavier666@lemm.ee on 01 May 02:36 collapse

I did it. The issue still lingers. Check my last comment for output.

ada@lemmy.blahaj.zone on 29 Apr 06:59 next collapse

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

xavier666@lemm.ee on 29 Apr 07:48 collapse

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.

ada@lemmy.blahaj.zone on 29 Apr 08:08 next collapse

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.

xavier666@lemm.ee on 29 Apr 08:55 collapse

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>.
ada@lemmy.blahaj.zone on 29 Apr 13:36 collapse

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

xavier666@lemm.ee on 30 Apr 06:43 collapse

Yeah, I ran it and rebooted it. But no change :(

I’ll do it once more just in case.

A_norny_mousse@feddit.org on 29 Apr 15:53 collapse

$ 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.ee on 30 Apr 06:56 collapse

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?

A_norny_mousse@feddit.org on 30 Apr 07:25 next collapse

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.

xavier666@lemm.ee on 30 Apr 10:56 next collapse

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.

A_norny_mousse@feddit.org on 30 Apr 14:54 collapse

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.

xavier666@lemm.ee on 01 May 07:44 collapse

I was experimenting. This might be helpful (lemm.ee/post/62662283/20097388)

BaumGeist@lemmy.ml on 30 Apr 09:01 collapse

(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.ee on 30 Apr 10:27 next collapse

user-IDs (prefixed with ‘#’)

And I thought it just meant a comment.

Thanks for this, I had no idea.

BaumGeist@lemmy.ml on 01 May 21:39 collapse

No problem, I love when people show curiosity, and I’m happy to help where I can

xavier666@lemm.ee on 30 Apr 10:56 collapse

!lemmysilver

unhrpetby@sh.itjust.works on 29 Apr 19:20 next collapse

From my experience a user account needs to be in the “wheel” group to elevate privileges through sudo. So try that.

A_norny_mousse@feddit.org on 01 May 09:55 collapse

Or in the sudo group. It differs.

mazzilius_marsti@lemmy.world on 30 Apr 18:15 next collapse

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

Logout/restart. You should be at the TTY, enter username and password to login. Then simply type sway

Now, test your sudo commands within this sway session. Do you still get the same bug?

xavier666@lemm.ee on 01 May 02:34 next collapse

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 groups command

In pure tty

$ groups
xavier666 adm cdrom sudo dip plugdev lpadmin lxd sambashare

The moment I enter into sway from inside the tty

$ groups 
xavier666 root
xavier666@lemm.ee on 01 May 07:42 collapse

I found something interesting, thanks to my friend

  • I removed the fix mentioned above. Now user does not have sudo access inside sway
  • I ran the command exec su - xavier666. It asked for my user password and the command was accepted.
  • My groups output looks normal (xavier666 is now part of sudo) and my permissions are fine
  • However, the problem reappears after a reboot

It is as if this user is an imposter with incorrect privileges 📮

A_norny_mousse@feddit.org on 01 May 10:00 collapse

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/sway if 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.
gnuhaut@lemmy.ml on 01 May 14:19 collapse

Can you provide output of which sway, sway --version, file $(which sway) and ls -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).

xavier666@lemm.ee on 02 May 10:34 collapse 

$ 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/sway

id pre and post login

uid=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 (xavier666 becomes part of sudo like expected) when I type exec su - xavier666 for 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.