summaryrefslogtreecommitdiff
path: root/daemon/gdm-launch-environment.c
Commit message (Collapse)AuthorAgeFilesLines
* gdm-launch-environment: Use g_auto*Alessandro Bono2023-04-281-36/+21
|
* gdm-launch-environment: Remove redudant checkAlessandro Bono2023-04-281-2/+0
| | | | | g_return_if_fail (GDM_IS_LAUNCH_ENVIRONMENT (object)) already checks it it is NULL.
* gdm-launch-environment: Add missing guards in public functionsAlessandro Bono2022-10-291-0/+8
|
* gdm-launch-environment: Use G_DECLARE_FINAL_TYPEAlessandro Bono2022-09-271-121/+119
| | | | Nobody derives it since commit be67db1c11868ea2788cece74bbe53e76522292c.
* launch-environment: add DATADIR to XDG_DATA_DIRSNaïm Favier2022-01-271-2/+2
| | | | so that gnome-session finds gnome-login.session
* daemon: Provide more flexibility for configuring display serverRay Strode2021-07-221-0/+9
| | | | | | | | | | | | | | | | | | | There's currently a way to disable wayland, but no way to disable Xorg. We currently prefer wayland if it's not disabled, but have no way to prefer Xorg without disabling wayland entirely. There's currently no way use legacy Xorg support at all if user display server support is enabled at a build time. This commit adds more flexibility to display server selection. It adds two new keys: XorgEnable and and PreferredDisplayServer. XorgEnable=false disables Xorg support entirely on seat 0. PreferredDisplayServer can be set to "wayland", "xorg", "legacy-xorg" or "none" to select which display server is used by default. If it's set to "wayland", it will fall back to "xorg". If it's set to "xorg" it will fall back to "wayland".
* launch-environment: Read XDG_DATA_DIRS from env.d for initial-setupCosimo Cecchi2021-07-091-9/+35
| | | | | | | | | | | In the initial setup session we may need to run a Flatpak application; Flatpak requires XDG_DATA_DIRS to include its locations to work correctly, but that's not set at the moment for the initial-setup session. This commit borrows the code from GdmSessionWorker to read XDG_DATA_DIRS from gdm's env.d machinery for the initial-setup session as well.
* gdm-launch-environment: Replace deprecated g_type_class_add_private()Robert Mader2019-08-131-6/+2
|
* Use G_PARAM_STATIC_STRIGS on propertiesNiels De Graef2019-01-071-12/+12
| | | | This prevents strings from being unnecessarily copied.
* launch-environment: use wayland for initial-setupRay Strode2018-08-311-1/+2
| | | | | | | | | | | While we've been using wayland by default for the login screen for a long time, and for the user session for somewhat less time, we never switched initial setup over. It's still using X11 for no good reason. This commit changes initial-setup to use wayland by default like everything else.
* launch-environment: Export library and gio pathsMarco Trevisan (Treviño)2018-05-071-0/+2
| | | | | | | If launching gdm from special environments (as jhbuild) these should be forwarded to the children greeter and launched apps too. https://bugzilla.gnome.org/show_bug.cgi?id=795886
* launch-environment: Set PATH via optional_environmentMarco Trevisan (Treviño)2018-05-071-2/+1
| | | | | | There's no need to add a different code path for this global env. https://bugzilla.gnome.org/show_bug.cgi?id=795886
* launch-environment: Order optional environment verticallyMarco Trevisan (Treviño)2018-05-071-6/+20
| | | | | | As per better readability. https://bugzilla.gnome.org/show_bug.cgi?id=795886
* launch-environment: don't name greeter log $display-greeter.log with user ↵Ray Strode2017-09-211-1/+5
| | | | | | | | | | displays If the X server is started as part of the session, we don't know the display up front. So don't try to encode the display in the log in that case. https://bugzilla.gnome.org/show_bug.cgi?id=787989
* launch-environment: Don't set DCONF_PROFILE for gnome-initial-setupDaniel Drake2017-04-041-2/+6
| | | | | | | | The locked down dconf profile should not be used for the initial setup session. This allows overridden values from the user profile to take effect. https://bugzilla.gnome.org/show_bug.cgi?id=780866
* Revert "launch-environment: Don't set DCONF_PROFILE for gnome-initial-setup"Mario Sanchez Prada2017-04-031-6/+2
| | | | | | | | | This should never have landed in the first place (I committed it by mistake while pushing the patch for bug 780862) and according to the discussion in bug 780866, it seems clear that this is not an upstreamable patch, not at least in its current form. This reverts commit 67ef79c125c34b66072ae00927b2c89f2c98f196.
* launch-environment: Don't set DCONF_PROFILE for gnome-initial-setupDaniel Drake2017-04-031-2/+6
| | | | | | The locked down dconf profile should not be used for the initial setup session. This allows overridden values from the user profile to take effect.
* launch-environment: implement hostname-selected signalRay Strode2017-03-311-0/+27
| | | | | | | | | | | We're connecting to a signal that isn't implemented. This commit adds the implementation. A slightly better fix might be to cut out some of the layers, of middle men passing around hostname-selected, but for now this is fine. https://bugzilla.gnome.org/show_bug.cgi?id=780787
* launch-environment: fix crasher when session-mode isn't setRay Strode2017-03-271-6/+7
| | | | | | This commit fixes a crasher when starting the indirect chooser. https://bugzilla.gnome.org/show_bug.cgi?id=780618
* launch-environment: Run gnome-session from PATHMichael Catanzaro2016-01-121-1/+1
| | | | | | | | Don't assume that gnome-session and gdm happen to be installed to the same location. This makes it easier to e.g. run gdm from /usr/local without installing gnome-session there as well. https://bugzilla.gnome.org/show_bug.cgi?id=760406
* daemon: fix code style in previous commitMichael Catanzaro2016-01-051-1/+1
| | | | | Ray asked me to change this on Bugzilla, but I didn't look at Bugzilla before I pushed it.
* launch-environment: disable gvfs except in initial setup modeMichael Catanzaro2016-01-051-0/+7
| | | | | | | gnome-initial-setup needs gvfs for remote avatar lookup. The greeter does not. https://bugzilla.gnome.org/show_bug.cgi?id=725584
* launch-environment: always use "gnome" session nowRay Strode2015-11-091-5/+0
| | | | | | | gnome-wayland isn't a thing anymore, wayland just uses the same session name. https://bugzilla.gnome.org/show_bug.cgi?id=757715
* launch-environment: set shell session mode in environmentRay Strode2015-11-091-0/+32
| | | | | | | | | | Right now we explicitly pass --mode=gdm to gnome-shell via a complicated set of overridden desktop files. This commit instead sets GNOME_SHELL_SESSION_MODE so we can just use the stock files. https://bugzilla.gnome.org/show_bug.cgi?id=757715
* Make gdm-session-worker exit cleanlyJoão Paulo Rechi Vita2015-07-141-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling gdm_session_stop_conversation() in gdm_launch_environment_stop() sends a SIGTERM to gdm-session-worker without waiting for it to die. The next step is calling gdm_session_close() to close the session, which stops all conversations of that session object, sending a 2nd SIGTERM to gdm-session-worker, this time waiting on its PID. On gdm-session-worker side, the first SIGTERM is caught by on_shutdown_signal(), its custom SIGTERM handler, which quits the mainloop and unrefs the worker object. Quiting the mainloop replaces the custom SIGTERM handler with the system default one (exit immediately). During the worker object class finalization gdm-session-worker may receive the 2nd SIGTERM, which leads to its immediate termination, without waiting for its children, which in turn leads to the main gdm process exit. Since systemd relies on the SIGCHLD from the main gdm process to tell when the service has stopped, this behavior breaks any unit that has a Conflicts=gdm.service entry and relies on the X server not being around when it is started. This commit removes the call to gdm_session_stop_conversation() in gdm_launch_environment_stop() and leaves it to be stopped in gdm_session_close(). [endlessm/eos-shell#4921] https://bugzilla.gnome.org/show_bug.cgi?id=752388
* session: load locale.conf from gdm-session.cRay Strode2015-07-021-106/+0
| | | | | | | | | | Right now we're not picking up changes to locale.conf completely at runtime. This commit moves reading locale.conf to a different place in the code, so that it's more effectively read and used. https://bugzilla.gnome.org/show_bug.cgi?id=751865
* session: drop session-type propertyRay Strode2015-06-121-2/+0
| | | | | | | | It was used by ConsoleKit to set the "LoginWindow" property on login screen sessions. it's not used by logind and ConsoleKit is gone now, so drop it. https://bugzilla.gnome.org/show_bug.cgi?id=743940
* drop consolekit supportRay Strode2015-06-121-3/+0
| | | | | | It was deprecated in 3.16 to be removed in 3.18 https://bugzilla.gnome.org/show_bug.cgi?id=743940
* legacy-display: ensure X11 display device is propagated to launch environmentRay Strode2015-04-101-1/+1
| | | | | | | | | | | | | Once the server associated with the login screen session is ready, we query its display device for ConsoleKit. This device needs to get propagated to the session to ensure ConsoleKit can track session activeness properly. This commit makes sure the display device is plumbed from the GdmServer object to the GdmLaunchEnvironment object where it gets used by the the login session (and subsequently the user session). https://bugzilla.gnome.org/show_bug.cgi?id=747351
* launch-environment: only pass on XAUTHORITY if setRay Strode2015-02-201-1/+2
| | | | | | | It's not set in a number cases now, so trying to send it along, leads to log spew. https://bugzilla.gnome.org/show_bug.cgi?id=744764
* launch-environment: add session-type propertyRay Strode2015-02-181-1/+45
| | | | | | | | | | The session-type property is analagous to the sd_login session type. It can be either "x11" or "wayland". This helps us decide whether to start a wayland session or an X session. https://bugzilla.gnome.org/show_bug.cgi?id=744764
* launch-environment: don't start dbus-daemonRay Strode2015-02-181-2/+1
| | | | | | | Either the wrappers will start one, or gnome-session will start one, or libdbus will start one. https://bugzilla.gnome.org/show_bug.cgi?id=744764
* display: start greeter/chooser session from display objectRay Strode2015-02-181-0/+106
| | | | | | | | | | | We're trying to get rid of the slave code, so we need to move responibility for launching the greeter to the display objects. This commit changes the display classes to set up a launch environment that the base class runs. https://bugzilla.gnome.org/show_bug.cgi?id=744764
* Revert "GdmLaunchEnvironment: allow a session bus address to be passed in"Ray Strode2015-02-181-40/+2
| | | | | | | | | | This reverts commit 5872d0738cf0bddd66d8aeae35bacadb04baa4c6. I pushed this patch prematurely. https://bugzilla.gnome.org/show_bug.cgi?id=693668 https://bugzilla.gnome.org/show_bug.cgi?id=744764
* launch-environment: Propagate XCURSOR_PATH and XDG_CONFIG_DIRSLuca Bruno2014-11-291-2/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=740632
* launch-environment: explicitly kill worker on stop even if session is runningRay Strode2014-05-141-7/+7
| | | | | | | | | | | | | | Right now, if the launch environment is stopped while it's running the whole process group of the session is killed. The theory is that doing this will kill both the worker and the dbus-daemon (and anything else). The problem is, now that gdm-simple-slave is gone, the worker is not part of the same process group as its children, so killing the process group of the session leaves the worker alive. This commit makes sure the worker is always explicitly killed. https://bugzilla.gnome.org/show_bug.cgi?id=729727
* launch-environment: disconnect session signal handlers when destroyedRay Strode2014-03-171-28/+35
| | | | | | | | | | | | 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
* launch-environment: don't disable GVFSRay Strode2014-03-031-3/+0
| | | | | | | | | | | | | | | | As an optimization we currently disable gvfs in greeter sessions (since they'll never need it). Now that we launch initial-setup in the same sort of environment, we're running into trouble because it relies on GVFS for fetching remote avatars. This commit eliminates the optimzation. The other option would be to disable GVFS for greeters, but enable it for initial-setup. In order to keep things simple, we forgo that for now, but may reconsider at a later time. https://bugzilla.gnome.org/show_bug.cgi?id=725584
* gdm-launch-environment: Remove duplicate DISPLAY setJasper St. Pierre2014-02-251-1/+0
| | | | GdmSession already sets this when setting up the environment.
* launch-environment: Tighten permissions on directories we createRui Matos2013-06-041-1/+1
| | | | | | | This is particularly important for gnome-initial-setup's home directory since private user data will be stored there. https://bugzilla.gnome.org/show_bug.cgi?id=701472
* GdmLaunchEnvironment: allow a session bus address to be passed inSimon McVittie2013-02-201-2/+40
| | | | | | | If we're given an explicit session bus address, don't wrap the command in a redundant dbus-launch. https://bugzilla.gnome.org/show_bug.cgi?id=693668
* Skip GIO modules in the login environmentGiovanni Campagna2013-01-301-0/+2
| | | | | | | We don't need GVFS or udisks in the GDM greeter, and not loading them reduces the startup times. https://bugzilla.gnome.org/show_bug.cgi?id=692903
* launch-environment: start dbus-daemon inside the user sessionRay Strode2012-09-251-333/+4
| | | | | | | | | | | | | | | | | We currently start dbus-daemon separately from the launch environment PAM session. This means all things activated by that bus get started in the wrong logind session and are missing important environment variables (such as XDG_RUNTIME_DIR). This commit deletes a bunch of code for managing the dbus session separately, and instead just makes it part of the session command (using dbus-launch as a wrapper around the session). Because we no longer have the specific PID of the bus daemon, we now stop the launch environment by killing the whole process group in one go. https://bugzilla.gnome.org/show_bug.cgi?id=684474
* worker: Copy environment from login session to reauth sessionsRay Strode2012-09-171-1/+2
| | | | | | | | | | | | | Reauthentication sessions depend on having the same environment as the session they were initiated from. This is important to make sure login prompts are in the right language, to make sure the kerberos credentials cache is looked up, and for various other reasons. This commit copies the environment from the login session to any new reauthentication sessions that get started after login. https://bugzilla.gnome.org/show_bug.cgi?id=684241
* daemon: Create home directory for greeter userColin Walters2012-09-151-0/+4
| | | | | | | | | | | For OSTree, I'm trying to move components to a model where they automatically create whatever directories/files are needed in /var. This helps with upgrade/downgrade scenarios. In GDM's case, this is pretty easy to do because we start with full root privileges. https://bugzilla.gnome.org/show_bug.cgi?id=630485
* daemon: Major cleanup of greeter environment setupColin Walters2012-09-151-172/+134
| | | | | | | | | | | | | | | | | First, we can't call a lot of this stuff inside a GSpawnChildSetupFunc; for example, g_warning() can try to lock a mutex; if another thread happened to be holding that mutex from before we forked, we'd deadlock. Thus, it needed to be extracted. Second, just drop the group-name property; nothing was using it, and it complicated the code. Third, the error handling was totally inconsistent and ugly; sometimes we would g_warning, other times we'd re-throw to the caller, other times we'd do both. Clean this up by consistently propagating errors up until the first public API that doesn't take a GError. https://bugzilla.gnome.org/show_bug.cgi?id=630485
* Trivial: Update FSF Address.Dominique Leuenberger2012-09-061-1/+1
| | | | Fix bug 683383.
* daemon: Rename GdmWelcomeSession to GdmLaunchEnvironmentJasper St. Pierre2012-08-011-0/+1249
"GdmWelcomeSession" was always a sort of bad name, as it is not a GdmSession, itself (it has-a GdmSession), and it's unnecessarily generic; it doesn't really have anything to do with "Welcome" or "Session" itself. It managed a non-user GdmSession, spawned the process in the correct environment (spawning a DBus daemon if need be) and made sure to keep track of it until it died. I think "GdmLaunchEnvironment" is an appropriate name for this. https://bugzilla.gnome.org/show_bug.cgi?id=678057