initial_session starts again if greeter terminates

Current behavior: If initial_session is used for auto-login and the user ends the session, then the greeter is launched. But if instead of logging in the user exits the greeter, then initial_session is started once again and access is gained without authentication.

Expected behavior: initial_session is run only once at startup. As it stands gtkgreeter has a cancel button that quits it, but even if that was removed, the initial_session should not be run again until greetd is restarted, because the greeter could crash.

As Issue #7 states auto-login is intended for users with full-disk encryption who do not want to enter their password twice on boot. The current behavior is dangerous in this case. Relaunching initial_session only makes sense if initial_session is a kiosk-like environment.

Additional information:

  • Version: 0.6.1
  • Distribution: Arch Linux

Configuration example:

command = "sh"
user = "jnt"
Assigned to
1 year, 4 months ago
3 months ago
No labels applied.

~kennylevinsen 1 year, 4 months ago

Initial sessions are never restarted by greetd. The issue here is that greetd itself is being restarted. greetd terminates if the greeter terminates without having done anything, to avoid hard-to-break crash-loops.

gtkgreet's cancel button at the very beginning simply exits gtkgreet, which is what triggers this issue. A simple fix is to only show the cancel button to stop a login flow, not at the beginning to terminate gtkgreet.

~jantatje 1 year, 4 months ago

I was not aware that greetd terminates. I'd argue that the "bug" then is in the supplied greetd.service systemd unit file. If greetd cannot remember that the initial_session was already launched before it was restarted, then the systemd unit should not restart greetd by default. Removing the cancel button to terminate gtkgreet would still be a good idea to prevent the user from accidentally terminating greetd, but in my opinion it is not enough to prevent unintended auto-login, because an attacker could still find a way to crash either the greeter or the compositor it is running on.

~kennylevinsen 1 year, 4 months ago

The "simple fix" was not intended as final fix, just a way to get combined initial+default sessions from "broken" to "usable".

The question is what the final fix will be. I'm not sure what a portable solution to tracking greetd start count from boot would look like (one might think about temp files, but /tmp can be persistent). Disabling auto-restart could be a workaround.

~alebastr referenced this from #12 1 year, 2 months ago

~apognu 5 months ago

Maybe this could use some kind of state file in /run? As I understand it, this is literally what we would need here, some runtime information that the initial session was already launched once since last boot.

And as far as I know, /run is never persisted across boots.

~kennylevinsen 4 months ago

There is no guarantee that /run or /var/run is a temporarily filesystem, but I guess we could make the path configurable if needed.

~apognu, would you be up for a a patch? :)

~apognu 4 months ago

~kennylevinsen Yeah I'll have stab at it and submit a patch.

~apognu 4 months ago

Patch is sent here.

~apognu referenced this from #12 4 months ago

~kennylevinsen REPORTED FIXED 3 months ago

Register here or Log in to comment, or comment via email.