search

kyngs / LibreLogin

Open-source, multiplatform, and highly customizable authentication plugin with outstanding features and API.
Mozilla Public License 2.0
164 stars 53 forks source link

The plugin crashes on aarch64 (ARM) #258

Closed frantisekhanzlikbl closed 2 months ago

frantisekhanzlikbl commented 2 months ago

Hi!

Currently, when trying to use the plugin with Velocity on an aarch64 machine, the plugin attempts to perform some initialisation, but probably tries to call some native code and crashes. The last log lines look like this:

Jun 16 00:32:51 oganesson velocity[1778136]: [00:32:51 INFO] [librelogin]: Loading messages...
Jun 16 00:32:51 oganesson velocity[1778136]: [00:32:51 WARN] [librelogin]: Sorry, but I've needed to reset the totp-show-info message because the process has significantly changed. Here is the original: Please scan the QR code on the map into your 2FA app. For example, Google Authenticator or Authy.
Jun 16 00:32:51 oganesson velocity[1778136]: When you are complete, please execute the /2faconfirm <code> command to finish the process.
Jun 16 00:32:51 oganesson velocity[1778136]: Disconnect to abort.
Jun 16 00:32:56 oganesson systemd[1]: velocity.service: Main process exited, code=dumped, status=31/SYS

I'm not sure how much is this in the hands of the plugin, or if it is entirely a fault of some library used, but I figured submitting an issue wouldn't hurt. :)

Please let me know if there is any debugging I can help with.

Version info:
LibreLogin 0.22.0
Velocity 3.3.0-SNAPSHOT (git-07f1f9e7-b396)
java openjdk 21 2023-09-19
OpenJDK Runtime Environment (build 21+35-nixos)
OpenJDK 64-Bit Server VM (build 21+35-nixos, mixed mode, sharing)
frantisekhanzlikbl commented 2 months ago

Oh, never mind, I just tested on an x86_64 machine and the behaviour is identical. Maybe this is not a problem with the arch, but a broken release?

Mystery solved. Turns out this has nothing to do with architecture, as one might easily tell from the systemd status 31/SYS.

The real problem is that for some reason, LibreLogin attempts to perform a fchown syscall during its initialisation, which results in systemd immediately killing it in my setup because velocity does not need (or should) run as a privileged user, so it only has access to the @system-service family of syscalls.

I could work around this by permitting Velocity to use the fchown syscall, but is there really a good reason for LibreLogin using it? I don't really like the idea of Velocity chowning stuff as it pleases. Should I open a new issue for that?

kyngs commented 2 months ago

Honestly: the plugin is open-source, if you want to impose restrictions on allowed syscalls, you need to adapt it yourself.

frantisekhanzlikbl commented 2 months ago

Fair enough. I'm sorry if I sounded needy; it was not the intention, I've just not put enough effort into properly communicating what I meant to.

Looking into this a bit, it seems like it's not even this plugin that does the chowning, but sponge's HOCON loader. There's probably not much that can be done on the plugin's side.

Thanks for the amazing work on this. It is greatly appreciated. :-)