Re: coredumpctl change in jeopardy due to SELinux bugs
----- Original Message -----
Hi,
Unfortunately the change deadline has passed, but our coredumpctl
change is not testable due to [1]. Additionally, ABRT is broken due to
[2]. We have workarounds for both issues, but it requires running
SELinux commands locally. Accordingly, is likely that FESCo will reject
the change at its next meeting.
I'm tired of prodding the SELinux developers via email and Bugzilla.
This saga has been ongoing since last summer, which is way too long. I
now have very, very serious doubts as to whether we should continue to
ship with SELinux enabled in the Workstation product. We clearly cannot
fix it even when it's breaking a critical developer feature that's a
priority for the WG... so what happens when it breaks anything less
important?
It broke creating galleries from Videos because of SELinux policies, it
broke all the iOS devices integration, it still breaks fwupd checking
for 8bitdo joypads. I usually run my systems with permissive SELinux,
because it's too much of a pain.
Now that the new systemd with restrictions is in rawhide, I would rather
we started using this functionality, meaning that the developers and
maintainers of those daemons are the ones saying what is correct behaviour
and what isn't.
For example, I recently restricted accesses in both fprintd and iio-sensor-proxy,
which interact with hardware:
https://cgit.freedesktop.org/libfprint/fprintd/tree/data/fprintd.service.in
https://github.com/hadess/iio-sensor-proxy/blob/master/data/iio-sensor-pr...
We need to start looking at shipping sandboxed applications. It makes
adding dependencies much less painful, and actually enhances security.
Cheers