Re: Grub, EFI, and SELinux
On Mon, May 4, 2020 at 10:20 AM Panu Matilainen wrote: [snip] > > I've been closing as duplicates of #1722766 but we are just getting > > too many bugs filed for this issue. > > It's an entirely cosmetical issue in rpm SELinux plugin but as innocent > maintainers are apparently getting bombarded because of it: > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-feefa460b1 > https://bodhi.fedoraproject.org/updates/FEDORA-2020-54205e879b > Thanks a lot! Best regards, Javier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Grub, EFI, and SELinux
On 5/4/20 10:17 AM, Javier Martinez Canillas wrote: On Sun, May 3, 2020 at 4:40 AM Jerry James wrote: On Sat, May 2, 2020 at 4:33 AM Christopher wrote: Those are bugs filed against RPM. Is the RPM package responsible for executing lsetfilecon, or is it the grub2 package? If the grub2 package, it seems to me that they should know that EFI partitions will never support lsetfilecon and they should never try. If it's RPM, then it looks like it is suppressed upstream and the fix will be incorporated eventually. I guess I don't know which component is actually responsible for causing the execution of lsetfilecon. You're right, but there is discussion of the grub2 issue in bug 1722766. A number of bugs have been filed against grub2 specifically: Nothing in the grub2 package executes restorecon for the files in /boot/efi. The problem is that rpm calls lgetxattr() for each entry in %files, regardless if the filesystem supports extended attributes or not: https://bugzilla.redhat.com/show_bug.cgi?id=1722766#c43 https://github.com/rpm-software-management/rpm/pull/976 https://bugzilla.redhat.com/show_bug.cgi?id=1819817 https://bugzilla.redhat.com/show_bug.cgi?id=1827922 https://bugzilla.redhat.com/show_bug.cgi?id=1829137 https://bugzilla.redhat.com/show_bug.cgi?id=1830399 So far, though, no word from the maintainer on those bugs. I've been closing as duplicates of #1722766 but we are just getting too many bugs filed for this issue. It's an entirely cosmetical issue in rpm SELinux plugin but as innocent maintainers are apparently getting bombarded because of it: https://bodhi.fedoraproject.org/updates/FEDORA-2020-feefa460b1 https://bodhi.fedoraproject.org/updates/FEDORA-2020-54205e879b - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Grub, EFI, and SELinux
On Sun, May 3, 2020 at 4:40 AM Jerry James wrote: > > On Sat, May 2, 2020 at 4:33 AM Christopher wrote: > > Those are bugs filed against RPM. Is the RPM package responsible for > > executing lsetfilecon, or is it the grub2 package? If the grub2 > > package, it seems to me that they should know that EFI partitions will > > never support lsetfilecon and they should never try. If it's RPM, then > > it looks like it is suppressed upstream and the fix will be > > incorporated eventually. I guess I don't know which component is > > actually responsible for causing the execution of lsetfilecon. > > You're right, but there is discussion of the grub2 issue in bug > 1722766. A number of bugs have been filed against grub2 specifically: > Nothing in the grub2 package executes restorecon for the files in /boot/efi. The problem is that rpm calls lgetxattr() for each entry in %files, regardless if the filesystem supports extended attributes or not: https://bugzilla.redhat.com/show_bug.cgi?id=1722766#c43 https://github.com/rpm-software-management/rpm/pull/976 > https://bugzilla.redhat.com/show_bug.cgi?id=1819817 > https://bugzilla.redhat.com/show_bug.cgi?id=1827922 > https://bugzilla.redhat.com/show_bug.cgi?id=1829137 > https://bugzilla.redhat.com/show_bug.cgi?id=1830399 > > So far, though, no word from the maintainer on those bugs. I've been closing as duplicates of #1722766 but we are just getting too many bugs filed for this issue. Best regards, Javier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Grub, EFI, and SELinux
On Sat, May 2, 2020 at 4:33 AM Christopher wrote: > Those are bugs filed against RPM. Is the RPM package responsible for > executing lsetfilecon, or is it the grub2 package? If the grub2 > package, it seems to me that they should know that EFI partitions will > never support lsetfilecon and they should never try. If it's RPM, then > it looks like it is suppressed upstream and the fix will be > incorporated eventually. I guess I don't know which component is > actually responsible for causing the execution of lsetfilecon. You're right, but there is discussion of the grub2 issue in bug 1722766. A number of bugs have been filed against grub2 specifically: https://bugzilla.redhat.com/show_bug.cgi?id=1819817 https://bugzilla.redhat.com/show_bug.cgi?id=1827922 https://bugzilla.redhat.com/show_bug.cgi?id=1829137 https://bugzilla.redhat.com/show_bug.cgi?id=1830399 So far, though, no word from the maintainer on those bugs. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Grub, EFI, and SELinux
On Fri, May 1, 2020 at 12:03 PM Jerry James wrote: > > On Fri, May 1, 2020 at 7:55 AM Christopher wrote: > > Can anybody tell me why the grub package seems to want to label files > > on the EFI partition during updates? > > I had thought that, by definition, EFI partitions were basically FAT, > > which doesn't support the extended attributes for SELinux contexts... > > > > So, why does the Grub package insist on attempting to label the EFI > > partition, as in the following? > > > > Upgrading: grub2-common-1:2.04-15.fc32.noarch > >2/127 > > error: lsetfilecon: (/boot/efi/EFI/fedora, > > system_u:object_r:boot_t:s0) Operation not supported > > > > I noticed this first on F31 for the first time, awhile back, but I > > figured it was harmless and would be fixed eventually. However, since > > it has been happening for months on F31, and still is happening on F32 > > now that I've upgraded, I'm wondering if there's a good reason why > > it's trying to do this. > > See: > https://bugzilla.redhat.com/show_bug.cgi?id=1722766 > https://github.com/rpm-software-management/rpm/pull/976 Those are bugs filed against RPM. Is the RPM package responsible for executing lsetfilecon, or is it the grub2 package? If the grub2 package, it seems to me that they should know that EFI partitions will never support lsetfilecon and they should never try. If it's RPM, then it looks like it is suppressed upstream and the fix will be incorporated eventually. I guess I don't know which component is actually responsible for causing the execution of lsetfilecon. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Grub, EFI, and SELinux
On Fri, May 1, 2020 at 7:55 AM Christopher wrote: > Can anybody tell me why the grub package seems to want to label files > on the EFI partition during updates? > I had thought that, by definition, EFI partitions were basically FAT, > which doesn't support the extended attributes for SELinux contexts... > > So, why does the Grub package insist on attempting to label the EFI > partition, as in the following? > > Upgrading: grub2-common-1:2.04-15.fc32.noarch >2/127 > error: lsetfilecon: (/boot/efi/EFI/fedora, > system_u:object_r:boot_t:s0) Operation not supported > > I noticed this first on F31 for the first time, awhile back, but I > figured it was harmless and would be fixed eventually. However, since > it has been happening for months on F31, and still is happening on F32 > now that I've upgraded, I'm wondering if there's a good reason why > it's trying to do this. See: https://bugzilla.redhat.com/show_bug.cgi?id=1722766 https://github.com/rpm-software-management/rpm/pull/976 -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Grub, EFI, and SELinux
Can anybody tell me why the grub package seems to want to label files on the EFI partition during updates? I had thought that, by definition, EFI partitions were basically FAT, which doesn't support the extended attributes for SELinux contexts... So, why does the Grub package insist on attempting to label the EFI partition, as in the following? Upgrading: grub2-common-1:2.04-15.fc32.noarch 2/127 error: lsetfilecon: (/boot/efi/EFI/fedora, system_u:object_r:boot_t:s0) Operation not supported I noticed this first on F31 for the first time, awhile back, but I figured it was harmless and would be fixed eventually. However, since it has been happening for months on F31, and still is happening on F32 now that I've upgraded, I'm wondering if there's a good reason why it's trying to do this. Thanks, Christopher ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
