Yeah no problem. This is a bug inside swhkd.

My guess is, swhkd is setuid root so it can open /dev/input/event* files, which are the keyboard devices.

These days, sway (or any other wayland compositor) gets access to keyboard events by talking to logind (or elogind or seatd if you don’t have systemd). But logind, I think, will only allow one program (e.g. sway) access to keyboard events at a time, so as not to allow keyloggers to be implemented.

This is also why sway used to support running setuid root, because that way it can access the devices without logind.

I think what swhkd does is:

1. Gets started as root by the kernel because of setuid bit and root ownership of the binary.
2. Opens /dev/input/event* files to read keyboard events. This is presumably what it wants root for.
3. Waits for keyboard events by reading the open file descriptor(s). When it finds one of the configured shortcuts, it calls fork(2) (to duplicate itself) followed by setuid(2) (in the forked process) to drop privileges and run as a normal user, and then execve(2) to execute your command.

The problem is that it messes up somewhere and doesn’t set the correct group membership. It would probably need to call initgroups(3) to correct this, I think.

I will also say, because that page says this is perfectly safe, that maybe the author(s) don’t know what they’re talking about, because frankly the fact you were a member of the root group, even though your user isn’t supposed to be, is already concerning and a minor privilege escalation. Setuid root binaries were an endless source of privilege escalation vulnerabilities in the past.

But then again, a typical sudo-enabled setup is already like you’re an admin user, so you’re already pretty much f-ed if your user account gets compromised. So whatever I guess.

You may want to report this bug to them.

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.

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

OK I’m convinced, that’s apparently how that works. I wonder why it’s designed that way.

Edit: OK, I looked at the docs, and they sure do make a broken symlink there. I still think it’s worth a try to create a non-broken link, maybe the docs are wrong. I would expect they would put a little note there, that yes, you really do want to create a broken symlink (if so, why not a regular file?), but then again its kernel docs and those aren’t the most friendly.

I also thought you were OP for some reason, sorry.

Edit2: If you look at the file listing later in the docs, you can see this:

./configs/c.1/ncm.usb0 -> ../../../../usb_gadget/g1/functions/ncm.usb0

Which does look like a real non-broken symlink, so I maintain the docs are wrong and you’re not supposed to make a broken symlink.

Original comment, silightly edited:

You misunderstand. I suspect OP cannot create the symlink, because it would be a broken symlink, not because the symlink is relative. Maybe you cannot create broken symlinks in the sysfs for some reason.

I was just trying to explain that a relative symlink is relative to the directory in which it resides. The target to the symlink should point to ../../functions/uvc.usb0 if you want it to point to something that exists. The ln command in OP’s listing would result in a broken symlink, since the specified path is not relative to the c.1 directory. It is relative to the working directory, but that’s wrong, that’s not what ln expects you to put there.

Maybe it needs to be a correct symlink, maybe that will solve the problem.

Do you mean you intend to create a broken symlink?

IDK how all that works but I will say that the result of this would (in a normal filesystem) create a link named configs/c.1/uvc.usb0 yes, but that link would point to functions/uvc.usb0 relative to its own dir. This doesn’t exist and your symlink would be broken, presumably the special file system there doesn’t like that.

Edit: Apparently that’s not the problem and you’re totally supposed to run an ln command that should logically result in a broken symlink, thanks to kernel driver sysfs abuse.

Yeah no problem. I’d like to point out that this puts a hole in your firewall. If you have something exposed via udp, and an attacker knows about your --sport rule or figures this out, they can connect to it just by setting their source port to 5353. You can check what’s listening on udp with ss -lun or sudo ss -lunp (for process info).

Also, I have looked up what @Eideen@lemmy.world said about dig not supporting mdns and I think they are correct. With mdns, because of the multicast nature, you can get replies from multiple computers, and that’s a pretty big difference to regular dns. How could it even reliably know it has gotten all the replies or if it should wait for more? It just sort of happens to work correctly if you get a single reply.

Also, and I also looked this up, mdns lookups will to go through avahi-daemon on regular glibc distros. The libnss-mdns plugin description for glibc says this:

nss-mdns tries to contact a running avahi-daemon for resolving host names and addresses and making use of its superior record cacheing. If Avahi is not available at lookup time, the lookups will fail.

As I said, I’m not sure about that.

Still, dig won’t be listening on port 5353 for the answer, it’ll open some random port, so the firewall rule for 5353 will not apply. And the conntrack rule, is my guess, also doesn’t apply, because what I think the conntrack module does is:

• Remembers about the outgoing connection (i.e. when dig sends its udp packet out): source port, destination IP and port
• Check incoming packets against this info, and lets them through if they appear to be an answer

Since the outgoing packet is going to multicast, and the incoming packet (I suspect) is coming from the IP of the machine that answers (a different IP therefore), conntrack wouldn’t be able to figure that out. The answer doesn’t match the outgoing packet that dig sends. Since this is just a hunch, I would try to confirm this by looking at the traffic in e.g. wireshark.

My hunch on what’s going on: Dig opens up a different udp port (it has to, there would be avahi-daemon listening on 5353). So it sends out to the multicast address on 5353, but the answer comes back from the actual IP of whoever is answering, to whatever port dig is listening on, and the connection tracking is not smart enough to figure out this should be let through?

You should look at the traffic with wireshark.

Also maybe that’s fine in practice? Do applications actually run their own mDNS queries? Maybe it all goes through avahi-daemon? That uses port 5353 so that would get an answer if it did the mDNS query instead of dig. But I’m not sure how this works, so that’s just a guess.

Yeah you’re right, thanks. I did figure this out on my own already, see my other comment:

Oh yeah that, so technically (and I was confused about this), the p in s/from/to/p is not the same as the p command, it’s a flag for the s command that tells it to print the output.

Yeah no problem.

What’s maybe interesting is how sed came to be. Back in early days of Unix, they had ed as their editor (or, as some old manpage says, “Ed is the standard text editor.”)

Sed has basically the same commands as ed. You typed 3d to delete the third line, or 10,20p to print lines 10 to 20. They only had teletypes back then, which are basically a keyboard and dot-matrix printer with one of those continuous papers for output, prior to when hardware terminals with CRT screens were a thing.

Anyway, someone thought it would be useful if you could put ed-style editing commands inside shell pipelines, and ed doesn’t work for that. It is used for interactively editing files in place, and so gets commands from stdin. You can’t pipe any files into it. So the “stream editor”, sed, was born.

Also interesting: There were improved modified versions of ed going around like em and later ex. The original vi was a “visual mode” extension for ex, and you can still run ex/ed commands from vi by typing : first, e.g. you can delete line 3 by typing :3d inside vi.

Oh yeah that, so technically (and I was confused about this), the p in s/from/to/p is not the same as the p command, it’s a flag for the s command that tells it to print the output. You could do multiple commands like /re/ {s/a/b/;p} for the same result, by using a {} block.

If you do, say, /re/ s/a/b/; p those would be separate command, the first does the thing on lines matching /re/, while the p has no address range (e.g. regex) associated with it, so it gets executed for all the lines.

What expressions?

I mean awk is more powerful, it has variables, function, can do arithmetic and format strings, and such proper scripting language features. And the GNU awk manual is rather well written.

You can do something like this to emulate grep:

sed -n '/myregex/p'

The -n suppresses auto-printing. That command should interpreted as: find line matching /myregex/ and then print (p) it.

You can then combine this with s (substitute):

sed '/myregex/ s/from/to/ p`

The complete command is then something like:

LANG=C df -h --output=avail,source | sed -n '/\/dev\/nvme0n1p2/ s/^\s*\([0-9.]\+[KMGT]\).*/\1/ p'

Note that the output can be something like 2.3G, but in my locale that would be 2,3G which is why I added LANG=C.

Easier IMHO is awk:

awk '/myregex/ {print $1}'

prints the first field.

There’s some wrong things in this article, and a thing worth mentioning.

Half-Life (and its mods like Counter-Strike) had Linux server versions, and a lot of dedicated servers ran on Linux, which I think is worth mentioning when talking about the history.

Steam wasn’t well received at first, people didn’t like that there was now this special launcher/downloader you had to use. Mind you they moved their old games onto Steam, so it’s not like you knew about this when you bought it. Also there weren’t any games on there except Half-Life and related titles, like HL mods that got their own release.

Contrary to what the article claims, MacOS does not support some outdated version of DirectX, it does not and never has supported DirectX at all. DirectX was only ever supported on Windows and XBox.

DirectX also was not well received at first. Here’s an old article from gamedev.net (2002):

What later became known as DirectX 1.0 ended up not being very widely accepted. It was buggy, slow, badly structured, and overly complex.

Of course, Microsoft wasn’t about to just give up. They kept working at it, asking the community for ways to improve it. The first truly viable version of DirectX was DirectX 3.0. A few years later, they released DirectX 5 (skipping 4 entirely), which was the first truly useful version. Incremental improvements were made with version 6. Then came DirectX 7.0.

DirectX 7 was the first one to actually be embraced by game developers. It worked well, making game programming reasonably easy, and a lot of people liked the interface.

So, the Manhattan Project started. Manhattan Project was Microsoft’s attempt at creating a set of APIs that would make the task of writing games for their platform significantly less painful. The questionable naming decision was, sadly, fully intentional: while Microsoft had most of the PC gaming on its side, the gaming industry as a whole was mostly dominated by game consoles from Japan.

WTF Microsoft.

Since you say the thing is working fine on Windows, there’s almost certainly a bug or several. I’d say probably a driver in the kernel, but could be something else. Changing distro or kernel version does sometimes help with that sort of thing, mainly because another distro may have newer or older kernels and other software, and bugs get both introduced and fixed every release.

Freezing issues can have lots reasons, including buggy apps, RAM exhaustion due to memory leaks, bugs in the graphics drivers or graphics stack more generally, various blocking I/O things taking unexpectedly long due to network issues or faulty hardware or drivers.

If you want a chance to figure this out, you probably need to run things in the terminal, like installing software updates through the apt and snap (?) cli utilities. GUIs are notoriously shit at reporting unexpected errors, whereas all sorts of programs (including GUI apps if you start them in a terminal) do regularly print warnings and error messages to stderr, which will show up in a terminal. This is because it’s easy for the programmers to do that with just single printf() (etc.) line.

For driver issues, looking at the kernel logs can sometimes show interesting things as well. I will say that, when looking at logs or terminal output, there often are warnings that are completely unrelated and/or harmless, and that’s not necessarily obvious to the user.

If this is a software issue, framework imho shouldn’t advertise their stuff being able to run Ubuntu if they cannot stay on top of issues that are happening in this configuration.

This is actual RAM used by the desktop environments that is not available for cache. That is the number he gets from top, it doesn’t include the disk cache. The DE won’t use less RAM even when Firefox needs it, because it is not cache, it cannot be dropped if needed, you just have less RAM available for you applications (or for the actual cache, for that matter).

Glad you got it working.