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

[xavier666@lemm.ee]

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?

[xavier666@lemm.ee]

Just the way I launch sway; via gdm.

[xavier666@lemm.ee]

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?

[a_norny_mousse@feddit.org]

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.

[a_norny_mousse@feddit.org]

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.

[baumgeist@lemmy.ml]

(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

[gnuhaut@lemmy.ml]

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]

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

[gnuhaut@lemmy.ml]

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 -l output)?

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.

[xavier666@lemm.ee]

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/swhkd

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