| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
explicitly picked
Right now we we only set the display mode when a user picks a session
from the session list. That means the wrong display mode will get used
if wayland is saved from a previous log in.
This commit makes sure the display mode gets set as soon as the user
credentials are established, since at the point log in is imminent.
https://bugzilla.gnome.org/show_bug.cgi?id=728204
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=728204
|
|
|
|
|
|
|
| |
We only want to set DISPLAY if the user session is sharing the display
with the login screen.
https://bugzilla.gnome.org/show_bug.cgi?id=728204
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a user runs su in their session, that switched user will now be
running in a session that doesn't belong to it. GDM won't allow a user
access to the worker process associated with the session in this case.
Instead, it will try to create a temporary just-in-time reauthentication
channel so reauthentication can happen without having the user talking to
another user's worker. Unfortunately, a logic error in the code means,
the user won't access to its own just-in-time channel.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=727982
|
|
|
|
|
|
|
|
|
|
| |
if a client creates a transient reauthentication session and then we reject
the client when it tries to connect to it, then we need to clean up
the associated session object.
This commit does that.
https://bugzilla.gnome.org/show_bug.cgi?id=727982
|
|
|
|
|
|
|
|
|
| |
If a client gets rejected because it's not allowed to connect
to a particular session, we really need to inform the owner
of the session object so it can do any clean up it needs to do,
if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=727982
|
|
|
|
|
|
|
|
| |
If no PATH is set, then the session worker tries to set one up,
based on guess. This commit changes GDM to just use the PATH given
to GDM itself, rather than guessing (and getting it wrong).
https://bugzilla.gnome.org/show_bug.cgi?id=727980
|
|
|
|
|
|
|
|
|
|
|
|
| |
GDM uses a worker to manage PAM for user sessions and
greeter sessions. For the latter case we shouldn't run
the various Pre/Post scripts, but commit
Sb48a305e71637181975fc7ec479a71079b6fbc broke that.
This commit changes the code to prevent those scripts
from getting run again.
https://bugzilla.gnome.org/show_bug.cgi?id=727703
|
|
|
|
|
|
| |
Set XDG_CURRENT_DESKTOP when DesktopNames is set in the session file.
https://bugzilla.gnome.org/show_bug.cgi?id=727546
|
|
|
|
| |
vnc sessions, for instance, aren't on a seat.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It looks like there were a couple of breaks when porting away from
ck-connector.
The first issue is that consolekit uses some hard-coded rules to decide
if a given session is associated with the hard-coded 'Seat1' or not.
One of these rules is the "x11-display-device" property being set. We
were setting the "display-device" property instead, which is not for
graphical sessions. This was causing a new seat to be dynamically
created each time gdm started which was causing us to send
ActivateSession requests to the wrong seat.
The second issue is that ActivateSession will "fail" with "Session
already active" errors. Ignore those.
https://bugzilla.gnome.org/show_bug.cgi?id=727072
|
|
|
|
|
|
|
|
| |
There was some confusion over multiple competing enabled variables.
This commit eliminates the confusion.
https://bugzilla.gnome.org/show_bug.cgi?id=680348
|
|
|
|
|
|
|
| |
Rename this function to be more descriptive after some discussion
with Matthias.
https://bugzilla.gnome.org/show_bug.cgi?id=726813
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the slave was merged to the main daemon process, the code for
doing autologin accounting was accidentally moved earlier in the
autologin process. This caused the greeter to create a login
screen and do autologin at the same time.
This commit defers the accounting until after the operation is
fully initiated.
https://bugzilla.gnome.org/show_bug.cgi?id=726813
|
|
|
|
|
|
|
| |
The previous patch missed one case of GDM_SESSION_DISPLAY_MODE_NEW_VT,
resulting in an undefined reference to jump_to_vt().
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
| |
fixes distcheck
|
|
|
|
|
|
|
| |
FreeBSD build broke, so this commit makes wayland a configure time
argument
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
|
|
|
|
| |
The previous commit uses weak references on weak references to manage
transient session lifecycles without doing proper accounting.
That was a bad idea. This commit uses a hash table to track things
more explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=726283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now, gnome-shell can't unlock screens running on an X server that
isn't managed by GDM (say Xvnc or startx). This is because GDM handles
the backend processing for unlocking, and it handles that backend
processing from the worker associated with the session. If there is no
worker associated with the session (as is the case with Xvnc and startx),
then there's no process to handle reauthentication.
This commit notices that case, and creates a transient worker on the fly
just to perform one off authentication for unlock of non-GDM managed
sessions.
https://bugzilla.gnome.org/show_bug.cgi?id=726283
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the future we're going to need to know more details about the
sender to know how to move forward (such as seat id, session id,
if it's remote, etc) in order to create a transient session soley
for reauthentication.
To prepare for that future, this commit adds the necessary
functionality to get_display_and_details_for_bus_sender.
https://bugzilla.gnome.org/show_bug.cgi?id=726283
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment we unconditionally set PAM_XDISPLAY
and PAM_XAUTHDATA based on values passed to the worker.
In a future commit, those values are going to become
stubs, so as a first step, this commit makes PAM_XDISPLAY
and PAM_XAUTHDATA optional.
https://bugzilla.gnome.org/show_bug.cgi?id=726283
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It doesn't make sense for it to do, and right now the shell does it
up front, waits for the failure, and then does the "right" thing
(opens a new auth session) after.
This commit makes the failure explicit, so we can subsequently make
other cases where a reauth channel is requested work even if there is
no session to channel to by implicitly creating a transient one just
in time. That will come later.
https://bugzilla.gnome.org/show_bug.cgi?id=726283
|
|
|
|
|
|
|
| |
... at least for now, until we land logind integration in mutter
and turn on the Xorg logind-aware codepath in gdm.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
| |
Simply look for "wayland-sessions" as a path element.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
| |
Add the wayland-sessions directory, as shipped by gdm.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GNOME is going to need a mode of operation in GDM where the session
manages its own display server. In this mode of operation, we won't
morph the login screen into a user session by reusing the same X server.
Instead, we reset the login screen to prepare it for a future login,
and then let GNOME or the session worker activate its own session.
This commit adds the prerequisite work needed to gdm-manager.c, but
only as dead code, since the way to "turn it on" is stubbed out to
always reuse the existing server.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
|
|
| |
The session display mode describes exactly how the worker
environment will set up VTs, and whether the greeter X server
will be reused for the user session.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
| |
This reverts commit 72ccb27377886b9998ad8b5b7a3b3070474f90f3.
We're going to take a different approach for this.
|
|
|
|
|
|
|
|
|
| |
It's possible for the server object to get freed before its
child watch fires (if the slave is stopped early), so
we can't rely on the child watch to main accounting on the active
servers list.
This commit changes the code over to use weak references instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GNOME is going to need a mode of operation in GDM where it manages its
own display. In this mode of operation, we won't morph the login
screen into a user session by reusing the same X server. Instead, we
reset the login screen to prepare it for a future login, and then let
GNOME activate its session on its own.
This commit adds the prerequisite work needed to gdm-manager.c, but
only as dead code, since the way to "turn it on" is stubbed out to
always return FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A greeter environment always has two sessions: the greeter session, and
the "user session".
The "user session" tracks the login PAM conversation. PAM conversations
need to be created without any user, so the name "user session" is a bit
of a misnomer.
The "user session" is created when the greeter is created, and exists
when we're sitting at the username prompt. When the username is entered,
we then start a session worker. When the verification conversation is
finished, we then log the user in. The same exact GdmSession follows
into the user session.
Traditionally, the user session is started on the same X server as the
greeter, so the GdmDisplay and GdmSlave all go with it. With the new
display server management, we need to make the GdmSession follow into
the user session created for the login, and then start a *new* user
session for the next user that logs in on the same greeter.
The name "seed session" tries to capture this. The GdmSession starts out
as a little seed, and with a username and password, will one day blossom
into a beautiful little user session which will one day live on its own,
free from the greeter that gave it life and nourished it.
It's the circle of life, and it moves us all.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have three cases for starting a session:
1) We migrate to an existing session. Simply tear down state
and switch.
2) We're starting a new session, and it's a traditional Xorg
server. Tear down the greeter, and keep the same X server and
GdmDisplay, and start a full user session.
3) We're starting a new session, but it's a display server. Keep the
greeter around and give it a new seed session, and start a full user
session.
The last two cases are really the two sides of the same coin, while the
migrated case is really a fast-path special case that doesn't involve
launching a user session in any case, so use a "goto out;" as a fast
return rather than an if/else.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
|
|
|
|
|
| |
In order for session unlocking to work properly, the session-id
property of the display object needs to match the session running
on the display. The display object's session-id property is bound
to the slave's session-id property, so this commit makes sure
the slave's session-id is updated to the user's session's id once
the session is started.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The signal handlers here are intended to be used if the slave itself
tries to stop, for instance if the server or greeter die, and will
try to finish the display on its own.
Letting the signal handler run again will finish the display *again*
after an idle, meaning we have this path:
gdm_display_finish
gdm_display_unmanage
on_server_stopped
queue_finish
... idle ...
gdm_display_finish
gdm_display_unmanage
on_server_stopped
queue_finish
...
This might have been an infinite loop, except for the fact that GDM
smartly has code to detect the failure state where the X server
starts up and stops sufficiently quickly, and in that case transitions
the display to the FAILED state, which causes GdmDisplayStore to
unref the last ref on the GdmDisplay.
Since the finish is still queued, finish_idle runs, and very quickly
discovers that our object is no longer a GdmDisplay, so this very
quickly manifests into a:
gdm_display_finish: assertion 'GDM_IS_DISPLAY (display)' failed
error. Not before poking a hole and corrupting some memory trying
to clear the finish_idle_id, however.
|
|
|
|
|
|
| |
These can't possibly be active and armed if we're disposing.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
|
| |
The GdmDisplay should only be cleaned up if it's finished
or failed.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
|
|
|
|
| |
For no particular reason, the slave has been kept as a separate process.
Integrate this into the main display process by simply making the display
keep a handle to a GdmSlave object. To keep the cleanup simple, we won't
remove the GdmSlave subtypes yet. A future cleanup should merge the slave
functionality into GdmDisplay and its subtypes.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
|
|
|
|
|
|
| |
The launch environment's session can actually live longer than the
environment itself. This is because the session creates internals
"conversation" objects that take a reference on the session, which
sometimes keeps it on life support.
This commit makes sure the session signal handlers for the launch
environment don't get run after the launch environment is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
|
|
| |
Pushing these up to the session worker dramatically simplifies the
interface for the slave, which will allow us to kill the slaves as
separate binaries.
Ideally, in the long-term, these scripts should go away.
|
|
|
|
|
| |
We still need to have it in the XDMCP chooser slave, since we need to
initialize the X server, even if we didn't start it ourselves.
|
|
|
|
|
|
|
| |
We're going to move the code that runs Init to gdm-server.c and
the code that runs PostLogin / PreSession to gdm-session-worker.c
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
|
|
|
| |
Server regeneration causes Xorg to re-emit the SIGUSR1 signal, which
*really* confuses our state machine. Since we also want to control
the server lifetime fairly closely, it doesn't really make sense for
it to ever trigger, so force it off.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
|
|
| |
And move gdm_session_cancel(); somewhere a bit related.
https://bugzilla.gnome.org/show_bug.cgi?id=726380
|
|
|
|
| |
This file has been flat out unused for quite a while.
|
| |
|
| |
|
|
|
|
|
|
|
| |
OpenBSD has no support for IPv4 to IPv6 mapping, so make check for the
required definitions before using them.
https://bugzilla.gnome.org/show_bug.cgi?id=725554
|