• 0 Posts
  • 15 Comments
Joined 2 years ago
cake
Cake day: June 5th, 2023

help-circle
  • Ok so it’s not the uinput permissions.

    When you use lightdm, do you use it to log into a Gnome wayland session, same as with GDM? Or is there any other difference between using GDM and LightDM? What exactly is/isn’t working, and how can you tell it is related to the XTEST extension?

    Also I can use the PS5 controller as a mouse just fine.

    Ok, this could maybe be the kernel driver creating a “real” touchpad device. Steam is able to create fake/virtual mouse and keyboard devices, I suspect that’s what steam uses XTEST and/or uinput for. So even though your PS5 touchpad works, that does not invalidate my theory that steam wants XTEST for mouse/keyboard input fakery, because that’s what exactly what XTEST is for.

    So technically, Steam wouldn’t require XTEST for controller input, it would require XTEST to map controller inputs to fake mouse or keyboard inputs. I don’t know what exactly steam does if XTEST isn’t present, like what exactly doesn’t work?

    And XTEST is an X11 protocol extension, it probably doesn’t work properly under Wayland anyway.

    The null here is concerning to me.

    Dunno, ‘(null)’ might just refer to the default connection (or server or screen or whatever X11 object this refers to), so not sure if this something to be concerned about. I presume X11 clients in general do work? Like xterm or xeyes work, right?

    I am having the same bug as in here :/

    The fact that you cannot log in may seem/look like that exact issue you linked to, but that’s from 2019 and may have a different cause. In general, GDM will start some executable, (i.e. gnome-session or something like that, or at least it used to be gnome-session, haven’t used gnome in a while) which if it exits/crashes this will kick you back to GDM. It could crash for many reasons.


    You should check the logs for sure for both issues. X11 session logs (relating to Gnome X11 not starting), should be in ~/.xsession-errors (or ~/.xsession-errors.old for the previous session, I think). There may be a /var/log/Xorg.0.log for xorg, which I guess could also be the thing crashing (maybe). There may be other things logged with journald that could be relevant. journalctl --user should show all the logs for the user session. Logs from Gnome, since it runs as your user, would presumably show up there. My guess is all the relevant logs for a Gnome wayland session would also be there, as well as (hopefully) Xwayland errors/warnings, since Xwayland is actually the thing that would report it doesn’t support XTEST.

    Note that journalctl likes to show the oldest logs first, so look at the timestamps. You can press G to scroll to the end. There are various ways to filter messages, look at journalctl --help. You might want to use --grep to look for anything related to XTEST or xwayland.

    Lightdm and GDM are systemd units (systemctl list-units), the logs would show with something like sudo journalctl -u lightdm.


  • Interesting. I will say I suspect still this is to make the controller act as a mouse or keyboard somehow, which steam can do.

    One interesting thing is that it says in the bug report, that steam also requires uinput, which is used to create virtual input devices from userspace. And maybe (speculating) you need that for XTEST to work on wayland or something, or maybe steam can use uinput instead of XTEST if it’s not available.

    Or maybe it’s security-related somehow (Regular programs being able to create virtual keyboards is kind of a security issue).

    For me the output of getfacl /dev/uinput will list my username with read/write permissions. I have no idea what is responsible for giving me this permission but there it is.

    Can you check with getfacl in both sessions?


  • I have never heard about this, can you link to your source for this? Also what’s the symptom here exactly?

    AFAIK steam and games directly use the kernel devices for controller input, not any X11 extensions.

    Edit: Wait!? Do you want to use the controller as keyboard + mouse? Inside of GDM? Because that might use XTEST after reading about it, since XTEST seems to be some kind of testing protocol that allows one to emulate a mouse.




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


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



  • gnuhaut@lemmy.mltoLinux@lemmy.mlHelp with sed commands
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    1 month ago

    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.




  • The Intercept ist hier die Originalberichterstattung. Es werden namentlich genannte Quellen zitiert mit überprüfbaren Fakten, viel glaubhafter kann so ein Bericht gar nicht sein. Die deutsche Presse stürzt sich ja nicht gerade auf das Thema, aber ich denke im Laufe der Woche wird schon noch irgendwer darüber berichten.

    Dazu passt, dass verschiedene Politiker genau das gefordert haben letztes Jahr:

    https://www.zdf.de/nachrichten/politik/deutschland/ausweisung-terror-verherrlichung-faeser-kabinett-100.html

    “Wer keinen deutschen Pass hat und hier terroristische Taten verherrlicht, der muss, wo immer möglich, ausgewiesen und abgeschoben werden” - so beschreibt Bundesinnenministerin Nancy Faeser (SPD) die Zielrichtung eines neuen Gesetzentwurfs aus ihrem Haus. Dieser wurde am heutigen Mittwoch im Kabinett beschlossen und soll nun schnellstmöglich im Bundestag eingebracht werden.

    Man beachte das “keinen deutschen Pass”. Nach kurzem googlen scheint es übrigens durchaus grundsätzlich erlaubt, EU-Bürger auszuweisen. Und:

    Die Besonderheit: Auf eine rechtskräftige Verurteilung, die ansonsten in den meisten Fallgruppen des Paragrafen 54 des Aufenthaltsgesetzes als Voraussetzung genannt ist, soll es nicht ankommen. Vielmehr soll es genügen, wenn der Tatbestand der Belohnung und Billigung von terroristischen Straftaten (Paragraf 140 Strafgesetzbuch) erfüllt sei - aber eben ohne Urteil.

    Kann gerade nicht herausfinden, ob das Gesetzt tatsächlich so verabschiedet wurde.