Bug 1699099 - gnome-initial-setup 3.32.0+ crashes due to SELinux denials (because it has execstack flag set, because meson 0.50.0 sets it when it shouldn't)
Summary: gnome-initial-setup 3.32.0+ crashes due to SELinux denials (because it has ex...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-initial-setup
Version: 30
Hardware: All
OS: Linux
high
urgent
Target Milestone: ---
Assignee: Rui Matos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa AcceptedBlocker
Keywords:
: 1699746 1700521 (view as bug list)
Depends On:
Blocks: F30FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2019-04-11 19:15 UTC by Adam Williamson
Modified: 2019-04-17 19:14 UTC (History)
23 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2019-04-17 19:14:10 UTC


Attachments (Terms of Use)
full backtrace, just in case we need it (13.57 KB, text/plain)
2019-04-11 19:22 UTC, Adam Williamson
no flags Details
audit.log with additional info (I hope) (116.65 KB, text/plain)
2019-04-13 02:03 UTC, Adam Williamson
no flags Details
missing gis in workstation ...0415 (817.99 KB, image/png)
2019-04-16 14:50 UTC, satellitgo
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Github mesonbuild meson issues 5268 None None None 2019-04-16 01:29 UTC

Description Adam Williamson 2019-04-11 19:15:17 UTC
openQA testing of the GNOME 3.32.1 megaupdate:

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

shows both tests that test install of a live image built with the update failed:

https://openqa.fedoraproject.org/tests/380990
https://openqa.fedoraproject.org/tests/380991

they both fail on boot after install, when gnome-initial-setup should appear to allow us to create a user account; instead the system just gets stuck at a blank desktop. No tty is available (so the tests could not upload any logs).

I reproduced this locally and found that g-i-s is crashing. Here's an extract of the traceback:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = {__val = {0, 94, 94245363888800, 94245364219872, 139849892722700, 139849892265069, 140730281494264, 139849825513084, 94245364220768, 94, 94245364220768, 94, 549755813888, 139849825090118, 94245364124096, 139849826385088}}
        pid = <optimized out>
        tid = <optimized out>
        ret = <optimized out>
#1  0x00007f31531f5895 in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x72, sa_sigaction = 0x72}, sa_mask = {__val = {139849892553507, 94244467376176, 140728898420736, 0, 90, 94245364219360, 139849892755296, 139849892777279, 139850342727680, 94245364219360, 17656426100140967680, 0, 94245364219360, 94245364219360, 91, 140730281494672}}, sa_flags = 1279880688, sa_restorer = 0x7f314c496df0 <__FUNCTION__.12074>}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007f3157254b53 in g_assertion_message (domain=<optimized out>, file=<optimized out>, line=<optimized out>, func=0x7f314c496df0 <__FUNCTION__.12074> "dconf_shm_open", message=<optimized out>) at ../glib/gtestutils.c:2878
        lstr = "93\000R\376\177\000\000\000\207\326\205\375\071\b\365\260Is5\267U\000\000\331lIL1\177\000"
        s = 0x55b73574bde0 "`\303t5\267U"
#3  0x00007f31572b090f in g_assertion_message_expr (domain=domain@entry=0x7f314c496b9f "dconf", file=file@entry=0x7f314c496cc0 "../shm/dconf-shm.c", line=line@entry=93, func=func@entry=0x7f314c496df0 <__FUNCTION__.12074> "dconf_shm_open", expr=expr@entry=0x7f314c496cd9 "memory != MAP_FAILED") at ../glib/gtestutils.c:2904
        s = 0x55b73574aeb0 "assertion failed: (memory != MAP_FAILED)"
#4  0x00007f314c49546e in dconf_shm_open (name=<optimized out>) at ../shm/dconf-shm.c:93
        shmdir = <optimized out>
        filename = 0x55b735734980 "/run/user/980/dconf/user"
        memory = 0xffffffffffffffff
        fd = 7
        __FUNCTION__ = "dconf_shm_open"
#5  0x00007f314c49447d in dconf_engine_source_user_reopen (source=0x55b73572d0f0) at ../engine/dconf-engine-source-user.c:82
        user_source = 0x55b73572d0f0
#6  0x00007f314c494178 in dconf_engine_source_refresh (source=0x55b73572d0f0) at ../engine/dconf-engine-source.c:57
        was_open = 0
        is_open = <optimized out>
#7  0x00007f314c491ebd in dconf_engine_acquire_sources (engine=engine@entry=0x55b735727cc0) at ../engine/dconf-engine.c:199
        i = 0
#8  0x00007f314c4931b6 in dconf_engine_get_state (engine=0x55b735727cc0) at ../engine/dconf-engine.c:995
        state = <optimized out>
        state = <optimized out>
#9  dconf_engine_watch_fast (engine=0x55b735727cc0, path=0x55b73572c000 "/org/gnome/desktop/interface/") at ../engine/dconf-engine.c:995
        num_establishing = 1
        num_active = <optimized out>
        __FUNCTION__ = "dconf_engine_watch_fast"
        ow = 0x55b735734910
        i = <optimized out>

That smelled a bit permissions-y to me, so of course I wondered if it was SELinux and...it is. Booting with enforcing=0, g-i-s appears just fine. The following denials are shown by ausearch:

----
time->Thu Apr 11 12:07:12 2019
type=AVC msg=audit(1555009632.514:225): avc:  denied  { execute } for  pid=1395 comm="gnome-initial-s" path="/etc/ld.so.cache" dev="dm-0" ino=692054 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ld_so_cache_t:s0 tclass=file permissive=1
----
time->Thu Apr 11 12:07:12 2019
type=AVC msg=audit(1555009632.647:226): avc:  denied  { execute } for  pid=1395 comm="gnome-initial-s" path="/usr/lib/locale/locale-archive" dev="dm-0" ino=929846 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:locale_t:s0 tclass=file permissive=1
----
time->Thu Apr 11 12:07:12 2019
type=AVC msg=audit(1555009632.657:227): avc:  denied  { execute } for  pid=1395 comm="gnome-initial-s" path="/run/user/980/dconf/user" dev="tmpfs" ino=31928 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:config_home_t:s0 tclass=file permissive=1
----
time->Thu Apr 11 12:07:17 2019
type=AVC msg=audit(1555009637.626:234): avc:  denied  { execute } for  pid=1395 comm="gnome-initial-s" path="/usr/lib/locale/C.utf8/LC_CTYPE" dev="dm-0" ino=1679 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:locale_t:s0 tclass=file permissive=1
----
time->Thu Apr 11 12:07:20 2019
type=AVC msg=audit(1555009640.645:235): avc:  denied  { execute } for  pid=1395 comm="gnome-initial-s" path="/usr/share/fonts/cantarell/Cantarell-Regular.otf" dev="dm-0" ino=527821 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:fonts_t:s0 tclass=file permissive=1
----
time->Thu Apr 11 12:07:25 2019
type=AVC msg=audit(1555009645.640:237): avc:  denied  { execute } for  pid=1395 comm="gnome-initial-s" path="/etc/ld.so.cache" dev="dm-0" ino=692054 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ld_so_cache_t:s0 tclass=file permissive=1
----
time->Thu Apr 11 12:07:25 2019
type=AVC msg=audit(1555009645.645:238): avc:  denied  { execute } for  pid=1395 comm="gnome-initial-s" path="/var/lib/sss/mc/passwd" dev="dm-0" ino=140710 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sssd_public_t:s0 tclass=file permissive=1
----
time->Thu Apr 11 12:07:59 2019
type=AVC msg=audit(1555009679.999:265): avc:  denied  { execute } for  pid=1395 comm="gnome-initial-s" path="/run/user/980/dconf/user" dev="tmpfs" ino=34435 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:config_home_t:s0 tclass=file permissive=1

Comment 1 Adam Williamson 2019-04-11 19:17:52 UTC
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.

Comment 2 Adam Williamson 2019-04-11 19:22 UTC
Created attachment 1554623 [details]
full backtrace, just in case we need it

Comment 3 Kalev Lember 2019-04-11 19:49:50 UTC
(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.

Comment 4 Adam Williamson 2019-04-11 19:56:42 UTC
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.

Comment 5 Adam Williamson 2019-04-11 22:01:31 UTC
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.

Comment 6 Kalev Lember 2019-04-11 22:57:22 UTC
Good detective work as usual :) Thanks, Adam!

Comment 7 Milos Malik 2019-04-12 07:43:55 UTC
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

Comment 8 Lukas Vrabec 2019-04-12 07:59:15 UTC
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.

Comment 9 Adam Williamson 2019-04-13 02:03 UTC
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.

Comment 10 Lukas Vrabec 2019-04-13 12:12:16 UTC
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.

Comment 11 Adam Williamson 2019-04-13 14:45:06 UTC
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.

Comment 12 Milos Malik 2019-04-15 07:30:45 UTC
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"

Comment 13 Michael Catanzaro 2019-04-15 16:02:14 UTC
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?

Comment 14 Lukas Vrabec 2019-04-15 16:11:45 UTC
Hi Ondro,

Could you please look on comment#13? 

Thanks,
Lukas.

Comment 15 Michael Catanzaro 2019-04-15 17:01:50 UTC
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."

Comment 16 Michael Catanzaro 2019-04-15 17:14:56 UTC
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 }

Comment 17 Matthias Clasen 2019-04-15 17:22:11 UTC
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 );

Comment 18 Ondrej Mosnacek 2019-04-15 18:31:02 UTC
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...

Comment 19 Matthias Clasen 2019-04-15 20:04:39 UTC
gnome-initial-setup makes no calls to personality() when run under gdb, and /proc shows personality of the process to be 00000000

Comment 20 Michael Catanzaro 2019-04-15 20:34:57 UTC
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.

Comment 21 Geoffrey Marr 2019-04-15 20:59:18 UTC
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

Comment 22 Adam Williamson 2019-04-15 23:22:15 UTC
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...

Comment 23 Michael Catanzaro 2019-04-15 23:40:43 UTC
(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.

Comment 24 Michael Catanzaro 2019-04-15 23:59:27 UTC
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.

Comment 25 Adam Williamson 2019-04-16 00:54:55 UTC
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.

Comment 26 Michael Catanzaro 2019-04-16 00:57:40 UTC
Bisected down to https://github.com/mesonbuild/meson/commit/b4f04a67de3dd13027be523d1c14e6e7485a9af5

Comment 27 Adam Williamson 2019-04-16 06:00:05 UTC
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.

Comment 28 Fedora Update System 2019-04-16 06:55:58 UTC
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

Comment 29 satellitgo 2019-04-16 14:50 UTC
Created attachment 1555587 [details]
missing gis in workstation ...0415

Comment 30 Adam Williamson 2019-04-16 14:54:06 UTC
*** Bug 1699746 has been marked as a duplicate of this bug. ***

Comment 31 satellitgo 2019-04-16 15:09:01 UTC
on reboot of install commented in 1699099#c29    .0415 with enforcing=0 started GIS and it ran sucessfully

Comment 32 satellitgo 2019-04-16 15:13:29 UTC
(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

Comment 33 Fabio Valentini 2019-04-16 15:52:27 UTC
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/

Comment 34 Michael Catanzaro 2019-04-16 16:02:50 UTC
Looks like it. You could leave a comment in that thread to let devs know we've figured it out.

Comment 35 Michael Catanzaro 2019-04-16 20:47:13 UTC
*** Bug 1700521 has been marked as a duplicate of this bug. ***

Comment 36 Fedora Update System 2019-04-16 22:01:12 UTC
dippi-2.7.3-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2a13be4497

Comment 37 Fedora Update System 2019-04-16 22:01:17 UTC
dippi-2.7.3-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2a13be4497

Comment 38 Fedora Update System 2019-04-16 22:07:37 UTC
elementary-files-4.1.7-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-bb7c97947f

Comment 39 Fedora Update System 2019-04-16 22:07:43 UTC
elementary-files-4.1.7-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-bb7c97947f

Comment 40 Fedora Update System 2019-04-16 22:08:36 UTC
elementary-photos-2.6.3-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-83c33a90d2

Comment 41 Fedora Update System 2019-04-16 22:43:32 UTC
lollypop-1.0.6-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-0a5a7e96d9

Comment 42 Fedora Update System 2019-04-16 23:05:15 UTC
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

Comment 43 Fedora Update System 2019-04-16 23:06:52 UTC
sequeler-0.7.0-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-d011ecc5b4

Comment 44 Fedora Update System 2019-04-16 23:06:56 UTC
sequeler-0.7.0-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-d011ecc5b4

Comment 45 Fedora Update System 2019-04-16 23:13:27 UTC
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

Comment 46 Fedora Update System 2019-04-16 23:13:31 UTC
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

Comment 47 Fedora Update System 2019-04-16 23:14:41 UTC
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

Comment 48 Fedora Update System 2019-04-16 23:14:45 UTC
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

Comment 49 Fedora Update System 2019-04-16 23:16:02 UTC
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

Comment 50 Fedora Update System 2019-04-16 23:16:07 UTC
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

Comment 51 Adam Williamson 2019-04-16 23:28:59 UTC
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?

Comment 52 Fedora Update System 2019-04-17 01:02:09 UTC
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

Comment 53 Fedora Update System 2019-04-17 01:02:12 UTC
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

Comment 54 Fedora Update System 2019-04-17 01:02:14 UTC
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

Comment 55 Fedora Update System 2019-04-17 01:02:17 UTC
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

Comment 56 Fedora Update System 2019-04-17 01:02:19 UTC
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

Comment 57 Fedora Update System 2019-04-17 01:02:21 UTC
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

Comment 58 Fedora Update System 2019-04-17 01:02:24 UTC
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

Comment 59 Fedora Update System 2019-04-17 01:02:36 UTC
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

Comment 60 Fedora Update System 2019-04-17 01:02:39 UTC
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

Comment 61 Fedora Update System 2019-04-17 01:02:52 UTC
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

Comment 62 Fedora Update System 2019-04-17 16:04:46 UTC
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.

Comment 63 Adam Williamson 2019-04-17 19:14:10 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.