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?
Michael
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1341829 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1419980
On 03/03/2017 11:40 AM, Michael Catanzaro wrote:
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?
Michael
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1341829 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1419980
Please propose [1] as a blocker bug for the release and open a ticket on the FESCo tracker to request that FESCo use its prerogative to declare this a blocker for the release.
On Fri, Mar 03, 2017 at 11:57:12AM -0500, Stephen Gallagher wrote:
On 03/03/2017 11:40 AM, Michael Catanzaro wrote:
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?
Michael
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1341829 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1419980
Please propose [1] as a blocker bug for the release and open a ticket on the FESCo tracker to request that FESCo use its prerogative to declare this a blocker for the release.
[1] is in MODIFIED and selinux-policy-3.13.1-235.fc26 was supposed to have the fix. Michael, are you saying the fix isn't working? Because I see no comment in the bug to that effect.
Putting that on the blocker list may be useful, but what would be more useful is testing the bug and reporting the results back.
On 03/03/2017 10:43 PM, Paul W. Frields wrote:
On Fri, Mar 03, 2017 at 11:57:12AM -0500, Stephen Gallagher wrote:
On 03/03/2017 11:40 AM, Michael Catanzaro wrote:
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?
Michael
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1341829 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1419980
Please propose [1] as a blocker bug for the release and open a ticket on the FESCo tracker to request that FESCo use its prerogative to declare this a blocker for the release.
[1] is in MODIFIED and selinux-policy-3.13.1-235.fc26 was supposed to have the fix. Michael, are you saying the fix isn't working? Because I see no comment in the bug to that effect.
Putting that on the blocker list may be useful, but what would be more useful is testing the bug and reporting the results back.
I add comment to BZ, it's fixed in the latest selinux-policy package for F26.
Lukas.
Hi,
Lukas just commented half an hour ago (thanks Lukas!) to say it's now fixed. There was no previous indication in the bug that a fix was available. So hopefully that's one of the two issues down....
Michael
Sorry I forgot update BZ but Fix is in the latest policy. Also, issue with abrt_dump_oops_t is already fixed in policy.
Please let me know if you have any troubles around SELinux policy, I'll try to fix it ASAP.
On 03/03/2017 11:14 PM, Michael Catanzaro wrote:
Hi,
Lukas just commented half an hour ago (thanks Lukas!) to say it's now fixed. There was no previous indication in the bug that a fix was available. So hopefully that's one of the two issues down....
Michael _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
OK, Lukas says the second issue is fixed now, too. \o/
I'm still concerned with how difficult it was to resolve this. :(
Michael
On Fri, Mar 03, 2017 at 04:43:37PM -0500, Paul W. Frields wrote:
On Fri, Mar 03, 2017 at 11:57:12AM -0500, Stephen Gallagher wrote:
On 03/03/2017 11:40 AM, Michael Catanzaro wrote:
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?
Michael
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1341829 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1419980
Please propose [1] as a blocker bug for the release and open a ticket on the FESCo tracker to request that FESCo use its prerogative to declare this a blocker for the release.
[1] is in MODIFIED and selinux-policy-3.13.1-235.fc26 was supposed to have the fix. Michael, are you saying the fix isn't working? Because I see no comment in the bug to that effect.
Putting that on the blocker list may be useful, but what would be more useful is testing the bug and reporting the results back.
Looks like from recent bug comments that both of these fixes are already in F26. Can you test to see if they take care of the issue?
----- 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-proxy...
We need to start looking at shipping sandboxed applications. It makes adding dependencies much less painful, and actually enhances security.
Cheers
On Fri, Mar 03, 2017 at 10:40:30AM -0600, Michael Catanzaro wrote:
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
This looks like it may be a candidate for Fedora Program Management's new "Prioritized bugs and issues" process. See https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_an...
I don't want to _over_ use this, but this kind of thing certainly seems like a potential candidate.
On Fri, 2017-03-03 at 12:14 -0500, Matthew Miller wrote:
This looks like it may be a candidate for Fedora Program Management's new "Prioritized bugs and issues" process. See https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_ bugs_and_issues_-_the_process
I don't want to _over_ use this, but this kind of thing certainly seems like a potential candidate.
See [1]. It's already been rejected, but I could submit the same bug again, I suppose.
Michael
On Fri, Mar 03, 2017 at 03:30:44PM -0600, Michael Catanzaro wrote:
See [1]. It's already been rejected, but I could submit the same bug again, I suppose.
Oh yeah: "It seems likely that this will end up fixed as a dependency of other changes in Fedora Workstation, so I don't think we need to call it out as requiring special attention". If that's not working, it might be indicative of bigger communication problems. But, in any case, I think if a prioritized bug is not accepted as such for a reason like the above, and then that reason is not working out, revisiting makes sense.
In any case... it seems like it *did* get fixed?
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?
I think it still needs to be shipped enabled, but I agree the whack-a-mole that the SELinux has become of late is quite the joke, anyone would think they didn't have a decent set of tests/test harness hooked into a CI system for every git pull request change that is made.
desktop@lists.fedoraproject.org
-
Bastien Nocera -
Lukas Vrabec -
Matthew Miller -
Michael Catanzaro -
Michael Catanzaro -
Paul W. Frields -
Peter Robinson -
Stephen Gallagher