| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The daemon startup had lots of swapping around of effective uid, and
aborted if the log/auth directories didn't have the expected permissions.
Honestly this makes no sense - we're uid 0, so let's just ensure
they're directories and call chown() ourself. I have no idea what the
"paranoia" here is about - if someone had managed to e.g. make a
symbolic link in /var to somewhere unexpected, there are plenty of
other ways they could attack the system.
Rather than aborting, let's just call mkdir()/chown()/chmod() and
check the return values.
https://bugzilla.gnome.org/show_bug.cgi?id=684315
|
|
|
|
|
|
|
|
| |
This fixes a bug where we'd try to call g_child_watch_add() on a 0
pid in case of error. More importantly, this moves us closer to
a sane error handling story where the default is to throw.
https://bugzilla.gnome.org/show_bug.cgi?id=684315
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
We were a little to excited about memory clean up in
x11_session_is_on_seat
This commit fixes that and the subsequent crashes.
|
|
|
|
|
| |
Don't bother creating a child watch if we're about to fail anyway.
Don't exit from gdm-server.c, we do clean up from gdm-simple-slave.c
|
| |
|
|
|
|
| |
Closes #684081
|
|
|
|
|
|
|
| |
gdm-autologin must reference common-account, not common-auth, otherwise no
module is loaded and the account phase fails.
https://bugzilla.gnome.org/show_bug.cgi?id=684057
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
The conversation-started message said "stopped" and the
conversation-stopped message said "started"
This commit flips 'em.
https://bugzilla.gnome.org/show_bug.cgi?id=684241
|
|
|
|
| |
<liverig@gmail.com>.
|
| |
|
|
|
|
|
|
|
| |
It's an issue that comes up over and over again.
Give in to the peer pressure and allow root login
by default. We warn in gnome-session now anyway.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This will allow clients such as gnome-shell to do runtime detection
of gdm and fallback gracefully if not available.
https://bugzilla.gnome.org/show_bug.cgi?id=683790
|
|
|
|
|
| |
GdmManager is a GdmDBusManagerSkeleton, so it must include that at
the beginning of the instance and class structures.
|
| |
|
|
|
|
| |
It's getting the types wrong, rework it to be (subjectively) clearer.
|
|
|
|
| |
This important for smooth boot transitions.
|
|
|
|
| |
Correct typo in method call name.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An inverted condition in the wants_autologin function means we tried
to start greeter when autologin is runnings.
Since autologin is usually much faster than loading GL/gnome-shell, this bug
is sort of spotty to reproduce.
This commit changes the "delay > 0" check to "delay == 0" which is a
correct indicator of autologin.
https://bugzilla.gnome.org/show_bug.cgi?id=682465
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When pam_open_session finishes, the session worker
is set up such that the next fork()/exec() may transition the
user to a user specific context (such as staff_t).
This makes sense for the first fork()/exec() (which is the user
login), but the worker may fork()/exec() other workers after login
for unlock operations. These workers need to run in a gdm context
not a user context.
This commit changes gdm-session-worker to manually reset the exec()
context after the first fork().
https://bugzilla.gnome.org/show_bug.cgi?id=683426
|
|
|
|
| |
This sort of reverts commit 378390b9b5639bbe37cf4ba06e2e4acf1587e1d8.
|
|
|
|
| |
Fix bug 683383.
|