Tails

#1 Updated by intrigeri 2016-05-18 09:53:22

Note that one still can log in with the “live” password.

#2 Updated by intrigeri 2016-05-18 10:36:01

On Jessie, gdm3 ships /usr/share/gnome-session/sessions/gdm-shell.session, but in Stretch it doesn’t, so it’s no big surprise that our own /usr/share/gnome-session/sessions/gdm-tails.session is not used.

Indeed, the GDM -speficic GNOME session and desktop file are gone:

commit 26006da375bc38afb270296e927d71180f6bed01
Author: Ray Strode <rstrode@redhat.com>
Date:   Mon Nov 9 10:57:16 2015 -0500

    data: drop override xsession files

    We now tell gnome-shell to use GDM mode a different
    way so we don't need to override the desktop files
    anymore.

    https://bugzilla.gnome.org/show_bug.cgi?id=757715


commit f66cdfcb29482bb3267f19de7c57394fe8189f39
Author: Ray Strode <rstrode@redhat.com>
Date:   Tue Feb 17 11:56:36 2015 -0500

    data: drop gdm-shell.session

    It's identical to gnome.session these days.  All GDMification comes
    from the overriden gnome-shell.desktop file.

    https://bugzilla.gnome.org/show_bug.cgi?id=744764

To see how it works nowadays: git grep -E -i '(gdm[_-]mode|launch_environment|session[_-]mode|session_class|isGreeter)' in GNOME Shell and GDM Git trees.

The login UI code lives in js/gdm/ in the GNOME Shell (yes!) repo nowadays. The components to run, depending on the mode (e.g. “gdm”, “lock-screen”, “user”) are listed in js/ui/sessionMode.js. Maybe we can patch this file to have the “gdm” mode start our greeter and hide the login dialog (with unlockDialog: undefined possibly)?

#4 Updated by intrigeri 2016-06-06 14:51:08

intrigeri wrote:
> The login UI code lives in js/gdm/ in the GNOME Shell (yes!) repo nowadays. The components to run, depending on the mode (e.g. “gdm”, “lock-screen”, “user”) are listed in js/ui/sessionMode.js. Maybe we can patch this file to have the “gdm” mode 1. start our greeter and 2. hide the login dialog (with unlockDialog: undefined possibly)?

Instead of patching that JS to make it start our Greeter (1), we could would be to configure the default gnome.session’s RequiredComponents= to always start our Greeter, via a wrapper that exits 0 when we’re not in GDM mode. Still, we need to patch GNOME Shell to tell it not to display its login screen (2), if it oherwise hides our own one; this can be done as suggested in the quoted text.

Another idea to solve both (1) and (2) would be to add a new mode (see /usr/share/gnome-shell/modes/classic.json) that would inherits from the “gdm” mode, and enable the component/extension we need. But asking GDM to tell GNOME Shell that we’re in $mode is a bit complicated: GDM defines its mode in GDM_SESSION_MODE in daemon/gdm-launch-environment.c to gdm. So, for this idea to work, we need to patch GDM.

Note that we can’t ship /usr/share/gnome-shell/modes/gdm.json since if we got the code right, loads _modes from its own source code first, and then doesn’t allow overriding an existing mode via $mode.json: it only allows inheriting from a parent mode, which is not a perfect solution for the Greeter’s use case as explained before.

#5 Updated by intrigeri 2016-07-30 09:52:55

On my today’s build of feature/stretch, I see the Greeter. It’s quite buggy though: no background picture, empty list of keyboard layouts, and once I click “Login” X disappears and I’m back on a text console. But then I can reach the GNOME session with CTRL+ALT+F2.

#6 Updated by alant 2016-08-13 02:09:05

I have been suggested at GUADEC to use the gnome-initial-setup infrastructure to plug our greeter in.

The conditions for it to be launched are in daemon/gdm-display.c:1426(wants_initial_setup), and is basically:

• no user accounts available (could we satisfy that?)
• gnome-initial-setup.session is available
• configuration key daemon/InitialSetupEnable is True

Then, daemon/gdm-launch-environment.c will connect as gnome-initial-setup with the session /usr/share/gnome-session/sessions/gnome-initial-setup.session (provided by debian package gnome-initial-setup), with a shell session mode initial setup (that should be OK for us).

To start a session gnome-initial-setup connects to GDM in gnome-initial-setup/pages/summary/gis-summary-page.c:176(log_user_in):

• gdm_client_get_greeter_sync
• gdm_client_get_user_verifier_sync
• gdm_user_verifier_call_begin_verification_for_user_sync

Good news is that gnome-initial-setup is an real GTK+ binary, as our greeter is. So tails-greeter could conflict with the gnome-initial-setup package and provide the gnome-initial-setup.session. We would then use a maintained way to plug in the greeter.

#7 Updated by intrigeri 2016-08-23 04:55:05

alant wrote:
> I have been suggested at GUADEC to use the gnome-initial-setup infrastructure to plug our greeter in.

This might be a good idea on the long term, but as said earlier the Greeter now shows up, so I doubt we’ll need this for Stretch => please track this elsewhere if you want, since this ticket is going away :)