Bug 1699099

Note, I think the fix for this should not go out as a separate Bodhi update; it should be edited into the GNOME megaupdate, so the fix goes together with the new g-i-s that seems to trigger the problem.

This would be a Final blocker, but not nominating it yet as the update is not stable.

Created attachment 1554623 [details]
full backtrace, just in case we need it

(In reply to Adam Williamson from comment #1)
> This would be a Final blocker, but not nominating it yet as the update is
> not stable.

I believe the update that regressed it was gnome-initial-setup 3.32.0 update (https://bodhi.fedoraproject.org/updates/FEDORA-2019-d5ee65dbc5) and that update is already in stable. 3.32.1 only has translation updates compared to 3.32.0.

Hum. openQA did not test the 3.32.0 update as g-i-s is not tagged as critpath in Bodhi (clearly it ought to be...), but this test has passed for other updates since that one was pushed stable, so...that *looks* like it's really 3.32.1 that introduced the issue.

Still, I'll try and check if I'm missing something.

OK, so I manually triggered openQA on the 3.32.0 update, and you're right - it fails there too:

https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=30&groupid=2&build=Update-FEDORA-2019-d5ee65dbc5

I think I worked out why this is, too. The update tests run on 'whatever is currently in the stable repos, plus the packages from the update'. For Branched, packages only actually appear in the repos after a successful distro compose; we have not had a successful F30 compose since Fedora-30-20190408.n.0 , so any packages pushed stable since that compose aren't in the repos.

I have a little hack in the tests that includes the Koji 'build' repo for Branched, so that packages pushed stable since the most recent compose *do* get pulled in...but that hack doesn't apply to the packages pulled into the live image in the live image build test (I'd have to hack up the kickstart a bit to make that work), so the live image is really including only packages from the stock repos, plus whatever is in the update.

So tests of other F30 updates right now aren't including g-i-s 3.32.0, which is why they're passing. Once we get a successful F30 compose, tests for other updates will likely start failing (unless we push a fix for this in the meantime).

Given that, I'll change my karma on the 3.32.1 update, since it's not making this worse. I'll also propose this as a Final blocker. Thanks! Criterion is "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" - this bug clearly violates that for the Workstation live.

Oh, for the record, I also adjusted the openQA scheduler to whitelist gnome-initial-setup updates so they will be tested in future.

Good detective work as usual :) Thanks, Adam!

Why is gnome-initial-setup trying to execute /etc/ld.so.cache or /usr/lib/locale/locale-archive ? SELinux denials in comment#0 look very weird. From my POV, SELinux only indicates that some SHM shenanigans are happening. How is it possible that gnome-initial-setup executes something which does not have an executable bit set.

To find out what is really going on, we need full auditing enabled.

How to enable full auditing in audit daemon?

1) Open /etc/audit/rules.d/audit.rules file in an editor.
2) Remove following line if it exists:
-a task,never
3) Add following line at the end of the file:
-w /etc/shadow -p w
4) Restart the audit daemon:
 # service auditd restart
5) Re-run your scenario.

Full auditing is useful when:
 * full paths to accessed objects are needed
 * certain audit event fields, which are normally hidden, should be visible

Thanks Milos for investigation. 

I have same questions. It looks like that SELinux did his job and blocked something weird, also It looks that new version of gnome was not tested by gnome developers in SELinux enforcing.

Created attachment 1554885 [details]
audit.log with additional info (I hope)

Is this what you need? I tried to hack up the test to enable the additional audit logging, here is audit.log from that run.

Hi Adam, 

The problem are these AVCs:

#============= xdm_t ==============
allow xdm_t avahi_t:dbus send_msg;
allow xdm_t config_home_t:file execute;
allow xdm_t fonts_t:file execute;
allow xdm_t ld_so_cache_t:file execute;
allow xdm_t locale_t:file execute;
allow xdm_t sssd_public_t:file execute;


gnome-initial-setup runs as xdm_t and for some reason it's require to execute to files like sssd_public_t or config_home_t od fonts_t. Which is weird, e.g: no confined process has allowed to execute sssd_public_t. So why gnome-initial-setup needs it? It looks like a bug in code. 

Moving to gnome-initial-setup component. Could somebody take a look ? 

Thanks,
Lukas.

The most obvious suspect I see in gnome-initial-setup 3.32.0 is this:

https://gitlab.gnome.org/GNOME/gnome-initial-setup/commit/6b9cca532e6ef942df8fdd3349f16d9d313a9895

Basically g-i-s has been changed to sort of 'ping' gdm as soon as it starts up. I'm guessing this may be the source of the issue.

Following SELinux denials are recorded in the attachment. Please notice that they are caused by mmap syscalls. Is the syscall executed with correct parameters?

type=AVC msg=audit(1555119943.536:231): avc:  denied  { execute } for  pid=1281 comm="gnome-initial-s" path="/usr/share/fonts/cantarell/Cantarell-Regular.otf" dev="dm-0" ino=281513 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:fonts_t:s0 tclass=file permissive=1
type=SYSCALL msg=audit(1555119943.536:231): arch=c000003e syscall=9 per=400000 success=yes exit=139916887052288 a0=0 a1=21a54 a2=1 a3=2 items=0 ppid=1022 pid=1281 auid=4294967295 uid=980 gid=978 euid=980 suid=980 fsuid=980 egid=978 sgid=978 fsgid=978 tty=tty1 ses=4294967295 comm="gnome-initial-s" exe="/usr/libexec/gnome-initial-setup" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=mmap AUID="unset" UID="gnome-initial-setup" GID="gnome-initial-setup" EUID="gnome-initial-setup" SUID="gnome-initial-setup" FSUID="gnome-initial-setup" EGID="gnome-initial-setup" SGID="gnome-initial-setup" FSGID="gnome-initial-setup"
type=MMAP msg=audit(1555119943.536:231): fd=14 flags=0x2
type=PROCTITLE msg=audit(1555119943.536:231): proctitle="/usr/libexec/gnome-initial-setup"

type=AVC msg=audit(1555119945.157:233): avc:  denied  { execute } for  pid=1281 comm="gnome-initial-s" path="/etc/ld.so.cache" dev="dm-0" ino=260617 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:ld_so_cache_t:s0 tclass=file permissive=1
type=SYSCALL msg=audit(1555119945.157:233): arch=c000003e syscall=9 per=400000 success=yes exit=139916461002752 a0=0 a1=15fc7 a2=1 a3=2 items=0 ppid=1022 pid=1281 auid=4294967295 uid=980 gid=978 euid=980 suid=980 fsuid=980 egid=978 sgid=978 fsgid=978 tty=tty1 ses=4294967295 comm="gnome-initial-s" exe="/usr/libexec/gnome-initial-setup" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=mmap AUID="unset" UID="gnome-initial-setup" GID="gnome-initial-setup" EUID="gnome-initial-setup" SUID="gnome-initial-setup" FSUID="gnome-initial-setup" EGID="gnome-initial-setup" SGID="gnome-initial-setup" FSGID="gnome-initial-setup"
type=MMAP msg=audit(1555119945.157:233): fd=20 flags=0x2
type=PROCTITLE msg=audit(1555119945.157:233): proctitle="/usr/libexec/gnome-initial-setup"

type=AVC msg=audit(1555119945.161:234): avc:  denied  { execute } for  pid=1281 comm="gnome-initial-s" path="/var/lib/sss/mc/passwd" dev="dm-0" ino=8199 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sssd_public_t:s0 tclass=file permissive=1
type=SYSCALL msg=audit(1555119945.161:234): arch=c000003e syscall=9 per=400000 success=yes exit=139916443049984 a0=0 a1=804528 a2=1 a3=1 items=0 ppid=1022 pid=1281 auid=4294967295 uid=980 gid=978 euid=980 suid=980 fsuid=980 egid=978 sgid=978 fsgid=978 tty=tty1 ses=4294967295 comm="gnome-initial-s" exe="/usr/libexec/gnome-initial-setup" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=mmap AUID="unset" UID="gnome-initial-setup" GID="gnome-initial-setup" EUID="gnome-initial-setup" SUID="gnome-initial-setup" FSUID="gnome-initial-setup" EGID="gnome-initial-setup" SGID="gnome-initial-setup" FSGID="gnome-initial-setup"
type=MMAP msg=audit(1555119945.161:234): fd=32 flags=0x1
type=PROCTITLE msg=audit(1555119945.161:234): proctitle="/usr/libexec/gnome-initial-setup"

type=AVC msg=audit(1555119957.899:237): avc:  denied  { execute } for  pid=1281 comm="gnome-initial-s" path="/run/user/980/dconf/user" dev="tmpfs" ino=33404 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:config_home_t:s0 tclass=file permissive=1
type=SYSCALL msg=audit(1555119957.899:237): arch=c000003e syscall=9 per=400000 success=yes exit=139917347696640 a0=0 a1=1 a2=1 a3=1 items=0 ppid=1022 pid=1281 auid=4294967295 uid=980 gid=978 euid=980 suid=980 fsuid=980 egid=978 sgid=978 fsgid=978 tty=tty1 ses=4294967295 comm="gnome-initial-s" exe="/usr/libexec/gnome-initial-setup" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=mmap AUID="unset" UID="gnome-initial-setup" GID="gnome-initial-setup" EUID="gnome-initial-setup" SUID="gnome-initial-setup" FSUID="gnome-initial-setup" EGID="gnome-initial-setup" SGID="gnome-initial-setup" FSGID="gnome-initial-setup"
type=MMAP msg=audit(1555119957.899:237): fd=35 flags=0x1
type=PROCTITLE msg=audit(1555119957.899:237): proctitle="/usr/libexec/gnome-initial-setup"

Here's what has me confused. The flags on these mmap calls are 0x2 (PROT_WRITE) or 0x1 (PROT_READ). There's clearly no PROT_EXEC involved anywhere, that would be 0x4. So SELinux says it's denying execute permission, but it appears that denial just doesn't at all correspond to what the application is actually trying to do. Right? Or is mmaping anything from the file denied on the basis that it could be copied to executable memory later?

To debug this further on the application side, we'd need a backtrace to the denied syscall (e.g. selinux could send a signal that causes a coredump to the application and we could examine all threads in the resulting backtrace). But I'm really skeptical that it's an application-side problem to me. It looks more like selinux has gone crazy?

Hi Ondro,

Could you please look on comment#13? 

Thanks,
Lukas.

Ah no sorry, Matthias noticed that I'm wrong: I was interpreting the flags argument as if it were the prot argument. There is a separate flags argument for prot than for the other flags. The 0x1 actually means MAP_SHARED and 0x2 means MAP_PRIVATE, which probably isn't interesting here.

Nevertheless, we're still skeptical that PROT_EXEC is being used here. Although we can't tell from the audit, it seems pretty unlikely. Matthias says: "looking at mmap calls in dconf, glib and freetype none of them touches PROT_EXEC."

E.g. here is the mmap used by dconf, from https://gitlab.gnome.org/GNOME/dconf/blob/7419a726a2dbaca7781cec4eeb65bd1334a523d7/shm/dconf-shm.c#L141:

shm = mmap (NULL, 1, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

which presumably corresponds to this AVC:

type=AVC msg=audit(1555119957.899:237): avc:  denied  { execute } for  pid=1281 comm="gnome-initial-s" path="/run/user/980/dconf/user" dev="tmpfs" ino=33404 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:config_home_t:s0 tclass=file permissive=1
type=SYSCALL msg=audit(1555119957.899:237): arch=c000003e syscall=9 per=400000 success=yes exit=139917347696640 a0=0 a1=1 a2=1 a3=1 items=0 ppid=1022 pid=1281 auid=4294967295 uid=980 gid=978 euid=980 suid=980 fsuid=980 egid=978 sgid=978 fsgid=978 tty=tty1 ses=4294967295 comm="gnome-initial-s" exe="/usr/libexec/gnome-initial-setup" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=mmap AUID="unset" UID="gnome-initial-setup" GID="gnome-initial-setup" EUID="gnome-initial-setup" SUID="gnome-initial-setup" FSUID="gnome-initial-setup" EGID="gnome-initial-setup" SGID="gnome-initial-setup" FSGID="gnome-initial-setup"
type=MMAP msg=audit(1555119957.899:237): fd=35 flags=0x1
type=PROCTITLE msg=audit(1555119957.899:237): proctitle="/usr/libexec/gnome-initial-setup"

Doesn't make sense for this to be denied as { execute }

Here is the one mmap call related to fonts (from freetype):

    stream->base = (unsigned char *)mmap( NULL,
                                          stream->size,
                                          PROT_READ,
                                          MAP_FILE | MAP_PRIVATE,
                                          file,
                                          0 );

Hm... there is some logic in the kernel that could cause PROT_READ mmaps to be checked also for PROT_EXEC:

https://elixir.bootlin.com/linux/v5.0.7/source/security/security.c#L921

Is there any chance that gnome-initial-setup is running with READ_IMPLIES_EXEC personality(2)? It would be *really* strange, but so far it's the only explanation that comes to my mind...

gnome-initial-setup makes no calls to personality() when run under gdb, and /proc shows personality of the process to be 00000000

I think you're reading it backwards... I read it as: if PROT_READ is specified and PROT_EXEC is not specified (check), and personality does NOT include READ_IMPLIES_EXEC (check), and the target file is not on a noexec mount (check), then add PROT_EXEC even if it wasn't originally specified. So that would explain where the PROT_EXEC is coming from, right? Looks like that code has not changed in a long time.

Discussed during the 2019-04-15 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria:

"A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" for all Workstation installs.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-04-15/f30-blocker-review.2019-04-15-16.03.txt

OK, so I have *definitely* confirmed that it is gnome-initial-setup-3.32.0-1.fc30 that triggers this.

It's easy to prove this, in fact. Grab this live image:

https://kojipkgs.fedoraproject.org/compose/branched/Fedora-30-20190408.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-30-20190408.n.0.iso

that's the last nightly before g-i-s 3.32.0-1 went stable; it contains gnome-initial-setup-3.30.0-2.fc30.x86_64.

Run an install from that ISO. Boot the installed system. Note that g-i-s runs fine. Reboot *without completing g-i-s* (very important). Do this as many times as you like; g-i-s always runs.

Now boot back to the live image. Mount the installed system:

mkdir -p /mnt/sysimage
mount /dev/mapper/fedora_localhost--live-root /mnt/sysimage
mount /dev/vda1 /mnt/sysimage/boot

(adjust for your install, obvs). Now update just g-i-s:

chroot /mnt/sysimage
dnf update https://kojipkgs.fedoraproject.org//packages/gnome-initial-setup/3.32.0/1.fc30/x86_64/gnome-initial-setup-3.32.0-1.fc30.x86_64.rpm

Note that this is the only package that gets updated - no other deps are pulled in or anything. Now exit the chroot and reboot to the installed system again, and note that the bug happens. g-i-s does not run properly, the boot gets stuck at an empty desktop. If you check the journal from a subsequent boot, AVCs are logged.

So the updated g-i-s was *definitely* the trigger for this - not selinux-policy or selinux or anything else. It's still possible the trigger is not a code change exactly, it could be some new build flag or GCC change or something. I will test a rebuild of g-i-s 3.30.0-2.fc30 with current build chain, and I'll also try some triage builds with different commits applied or reverted...

(In reply to Michael Catanzaro from comment #20)
> I think you're reading it backwards... I read it as: if PROT_READ is
> specified and PROT_EXEC is not specified (check), and personality does NOT
> include READ_IMPLIES_EXEC (check),

Matthias has once again pointed out I'm the one reading this backwards... PROT_EXEC is only added if READ_IMPLIES_EXEC is there, so that makes a lot more sense.

We found:

$ execstack -q /usr/libexec/gnome-initial-setup
X /usr/libexec/gnome-initial-setup

which is not there in the 3.30 RPM. So that explains why selinux is blocking it. We don't yet know why that's there, though.

So, we are fairly convinced that this is probably being done by meson 0.5.0. So far everything we checked built with meson since meson 0.5.0 landed in the buildroot (on 2019-03-25) has the execstack flag set on its main executable, while everything we checked that was built before meson 0.5.0 landed does not have it set.

Bisected down to https://github.com/mesonbuild/meson/commit/b4f04a67de3dd13027be523d1c14e6e7485a9af5

This affects:

* Rawhide builds since 2019-03-10 11:39:37 UTC
* F29 builds(!) since 2019-03-13 12:07:34 UTC
* F30 builds since 2019-03-25 02:01:36 UTC

I have built meson-0.50.0-4 for F29, F30 and Rawhide with the revert backported, and submitted buildroot overrides for F29 and F30, so all packages built since around about now should not have the bug.

I am currently trying to find and rebuild all packages built using meson since those dates, then I will use my best judgment to submit new updates or edit existing updates in appropriate batches.

gnome-initial-setup-3.32.1-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ac2a21ff07

Created attachment 1555587 [details]
missing gis in workstation ...0415

*** Bug 1699746 has been marked as a duplicate of this bug. ***

on reboot of install commented in 1699099#c29    .0415 with enforcing=0 started GIS and it ran sucessfully

(In reply to satellitgo from comment #31)
> on reboot of install commented in 1699099#c29    .0415 with enforcing=0
> started GIS and it ran sucessfully

bug 1690429  ff icon missing is on the workstation .0415 when started with enforcing=0

Adam, thanks for rebuilding my packages with the fixed meson.

I guess this is related to: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZRTK3WK3Q6TIQYGKB4XVFHWK4BXXFPRB/

Looks like it. You could leave a comment in that thread to let devs know we've figured it out.

*** Bug 1700521 has been marked as a duplicate of this bug. ***

dippi-2.7.3-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2a13be4497

dippi-2.7.3-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2a13be4497

elementary-files-4.1.7-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-bb7c97947f

elementary-files-4.1.7-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-bb7c97947f

elementary-photos-2.6.3-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-83c33a90d2

lollypop-1.0.6-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-0a5a7e96d9

cutter-re-1.8.0-3.fc30 radare2-3.4.1-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-88abfa74cb

sequeler-0.7.0-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-d011ecc5b4

sequeler-0.7.0-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-d011ecc5b4

switchboard-plug-bluetooth-2.2.2-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-6241dc4fc3

switchboard-plug-bluetooth-2.2.2-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-6241dc4fc3

switchboard-plug-mouse-touchpad-2.2.0-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-37efac3628

switchboard-plug-mouse-touchpad-2.2.0-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-37efac3628

switchboard-plug-sound-2.2.1-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-dd1e9638ab

switchboard-plug-sound-2.2.1-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-dd1e9638ab

So to explain what's going on with the updates...there are two main updates for Fedora 29 (not marked as linked to this bug) and Fedora 30:

Fedora 29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-27e7b92407
Fedora 30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ac2a21ff07

These contain meson itself, and most of the packages that needed rebuilding because they got built with meson 0.50.0.

Some of the packages that got rebuilt, however, already had updates pending. For these, I edited the rebuild into the existing update, and - for Fedora 30 updates - marked the update as associated with this bug.

So, the release-blocking aspects of this should be resolved when the main Fedora 30 update goes stable. For the other updates, I'd say we should count them as having freeze exceptions *if the current stable build was done with 0.50.0* (which is the case if there was an update built with 0.50.0 that got pushed stable, then a *second* update, the one I edited). For cases where the current stable build was done with 0.49, we shouldn't push those during the freeze. I'll try and take care of that.

Does anyone object to this plan?

cutter-re-1.8.0-3.fc30, radare2-3.4.1-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-88abfa74cb

elementary-files-4.1.7-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-bb7c97947f

switchboard-plug-sound-2.2.1-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-dd1e9638ab

switchboard-plug-bluetooth-2.2.2-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-6241dc4fc3

dippi-2.7.3-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2a13be4497

switchboard-plug-mouse-touchpad-2.2.0-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-37efac3628

sequeler-0.7.0-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-d011ecc5b4

at-spi2-core-2.32.1-2.fc30, atomix-3.32.1-2.fc30, bijiben-3.32.1-2.fc30, containers-0.8.0-8.alpha.9.fc30, dav1d-0.2.1-3.fc30, dbus-broker-20-3.fc30, dsymbol-20181014gitec28618-8.fc30, egl-wayland-1.1.2-3.fc30, elementary-camera-1.0.4-2.fc30, elementary-code-3.1.1-2.fc30, elementary-terminal-5.3.4-2.fc30, eog-3.32.1-2.fc30, ephemeral-5.0.1-2.fc30, file-roller-3.32.1-2.fc30, fondo-1.2.2-4.20190324git71d97ee.fc30, fuse-2.9.9-3.fc30, fwupd-1.2.7-2.fc30, gamemode-1.2-4.fc30, geocode-glib-3.26.1-2.fc30, gir-to-d-0.18.0-4.fc30, glib-networking-2.60.1-2.fc30, glib2-2.60.1-2.fc30, gnome-bluetooth-3.32.1-2.fc30, gnome-books-3.32.0-3.fc30, gnome-boxes-3.32.0.2-2.fc30, gnome-builder-3.32.1-4.fc30, gnome-calculator-3.32.1-2.fc30, gnome-characters-3.32.1-2.fc30, gnome-control-center-3.32.1-2.fc30, gnome-desktop3-3.32.1-2.fc30, gnome-disk-utility-3.32.1-2.fc30, gnome-initial-setup-3.32.1-2.fc30, gnome-maps-3.32.1-2.fc30, gnome-music-3.32.1-2.fc30, gnome-shell-extension-gsconnect-21-2.fc30, gnome-software-3.32.1-2.fc30, gnome-system-monitor-3.32.1-2.fc30, gnome-weather-3.32.1-2.fc30, gobject-introspection-1.60.1-2.fc30, group-service-1.1.0-5.fc30, gvfs-1.40.1-2.fc30, libdazzle-3.32.1-2.fc30, libdparse-0.9.9-7.fc30, libinput-1.13.1-2.fc30, libmodulemd-2.2.3-3.fc30, libnotify-0.7.8-2.fc30, libplacebo-1.18.0-2.fc30, libsoup-2.66.1-2.fc30, libxmlb-0.1.8-2.fc30, mate-user-admin-1.4.1-2.fc30, mesa-19.0.2-3.fc30, meson-0.50.0-4.fc30, mpris-scrobbler-0.3.2-2.fc30, msgpack-d-1.0.0-0.6.beta.7.fc30, polari-3.32.0-3.fc30, reportd-0.6.6-2.fc30, shotwell-0.31.0-2.fc30, signon-glib-2.1-4.fc30, simple-scan-3.32.2-2.fc30, stdx-allocator-2.77.2-7.fc30, switchboard-plug-display-2.1.7-2.fc30, switchboard-plug-pantheon-shell-2.8.1-2.fc30, systemd-241-7.gita2eaa1c.fc30, toolbox-0.0.8-2.fc30, wingpanel-2.2.3-2.fc30, zchunk-1.1.1-3.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ac2a21ff07

lollypop-1.0.6-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0a5a7e96d9

elementary-photos-2.6.3-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-83c33a90d2

at-spi2-core-2.32.1-2.fc30, atomix-3.32.1-2.fc30, bijiben-3.32.1-2.fc30, containers-0.8.0-8.alpha.9.fc30, dav1d-0.2.1-3.fc30, dbus-broker-20-3.fc30, dsymbol-20181014gitec28618-8.fc30, egl-wayland-1.1.2-3.fc30, elementary-camera-1.0.4-2.fc30, elementary-code-3.1.1-2.fc30, elementary-terminal-5.3.4-2.fc30, eog-3.32.1-2.fc30, ephemeral-5.0.1-2.fc30, file-roller-3.32.1-2.fc30, fondo-1.2.2-4.20190324git71d97ee.fc30, fuse-2.9.9-3.fc30, fwupd-1.2.7-2.fc30, gamemode-1.2-4.fc30, geocode-glib-3.26.1-2.fc30, gir-to-d-0.18.0-4.fc30, glib-networking-2.60.1-2.fc30, glib2-2.60.1-2.fc30, gnome-bluetooth-3.32.1-2.fc30, gnome-books-3.32.0-3.fc30, gnome-boxes-3.32.0.2-2.fc30, gnome-builder-3.32.1-4.fc30, gnome-calculator-3.32.1-2.fc30, gnome-characters-3.32.1-2.fc30, gnome-control-center-3.32.1-2.fc30, gnome-desktop3-3.32.1-2.fc30, gnome-disk-utility-3.32.1-2.fc30, gnome-initial-setup-3.32.1-2.fc30, gnome-maps-3.32.1-2.fc30, gnome-music-3.32.1-2.fc30, gnome-shell-extension-gsconnect-21-2.fc30, gnome-software-3.32.1-2.fc30, gnome-system-monitor-3.32.1-2.fc30, gnome-weather-3.32.1-2.fc30, gobject-introspection-1.60.1-2.fc30, group-service-1.1.0-5.fc30, gvfs-1.40.1-2.fc30, libdazzle-3.32.1-2.fc30, libdparse-0.9.9-7.fc30, libinput-1.13.1-2.fc30, libmodulemd-2.2.3-3.fc30, libnotify-0.7.8-2.fc30, libplacebo-1.18.0-2.fc30, libsoup-2.66.1-2.fc30, libxmlb-0.1.8-2.fc30, mate-user-admin-1.4.1-2.fc30, mesa-19.0.2-3.fc30, meson-0.50.0-4.fc30, mpris-scrobbler-0.3.2-2.fc30, msgpack-d-1.0.0-0.6.beta.7.fc30, polari-3.32.0-3.fc30, reportd-0.6.6-2.fc30, shotwell-0.31.0-2.fc30, signon-glib-2.1-4.fc30, simple-scan-3.32.2-2.fc30, stdx-allocator-2.77.2-7.fc30, switchboard-plug-display-2.1.7-2.fc30, switchboard-plug-pantheon-shell-2.8.1-2.fc30, systemd-241-7.gita2eaa1c.fc30, toolbox-0.0.8-2.fc30, wingpanel-2.2.3-2.fc30, zchunk-1.1.1-3.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

So I tested and confirmed the main update, which has been pushed stable, really does fix the blocker issue here (g-i-s not running). Given that, to avoid confusion, I think we should close this bug now.

I have filed https://bugzilla.redhat.com/show_bug.cgi?id=1701012 as a follow-up to track the updates that have not yet been pushed stable. I will edit those updates and mark them as associated with that bug instead of this one.