(I'm filing this against the grub2 package, but it affects the shim-signed package equally.)

Description of problem:

The grub2-efi-x64 package packages files under /boot/efi with the following attributes:

drwxr-xr-x    2 root    root  /boot/efi/EFI/redhat
drwxr-xr-x    2 root    root  /boot/efi/EFI/redhat/fonts
-rwxr-xr-x    1 root    root  /boot/efi/EFI/redhat/fonts/unicode.pf2
-rw-r--r--    1 root    root  /boot/efi/EFI/redhat/grub.cfg
-rwx------    1 root    root  /boot/efi/EFI/redhat/grubenv
-rwxr-xr-x    1 root    root  /boot/efi/EFI/redhat/grubx64.efi

The shim-x64 package packages files under /boot/efi with the following attributes:

-rw-r--r--    1 root    root  /boot/efi/EFI/BOOT/BOOTX64.EFI
-rw-r--r--    1 root    root  /boot/efi/EFI/BOOT/fbx64.efi
-rw-r--r--    1 root    root  /boot/efi/EFI/redhat/BOOT.CSV
-rw-r--r--    1 root    root  /boot/efi/EFI/redhat/BOOTX64.CSV
-rw-r--r--    1 root    root  /boot/efi/EFI/redhat/mmx64.efi
-rw-r--r--    1 root    root  /boot/efi/EFI/redhat/shim.efi
-rw-r--r--    1 root    root  /boot/efi/EFI/redhat/shimx64-redhat.efi
-rw-r--r--    1 root    root  /boot/efi/EFI/redhat/shimx64.efi

However, the /boot/efi filesystem is an EFI System Partition (ESP), which is simply a FAT partition with a particular type code. FAT partitions do not support individual file access modes. Instead, Linux generates fake mode attributes for directories/files in vfat filesystems using the umask/dmask/fmask fstab(5) options.

Effectively, this means that while the mode for files can be set when a vfat filesystem is mounted, all files in the vfat filesystem will appear to have the same mode. Similarly, the mode of directories can be specified, but all directories will have that mode.

Since the grub2-efi-x64 and shim-x64 packages contribute files under /boot/efi with varying file modes, and because neither package employs the rpm %verify directive to prevent rpm --verify from attempting to verify the file modes, there is no combination of umask/dmask/fmask mount options that will allow the /boot/efi ESP to be mounted without rpm --verify flagging one or more files under /boot/efi as having invalid file modes.

Thus, this is a packaging error, and should be corrected.

This might not seem like a big deal, but on hosts that are required to comply with the United States Government Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs), when a package's on-disk contents differs in owners, groups, or file modes from what the package database asserts is correct, that is a Category I finding (the most severe finding).

Version-Release number of selected component (if applicable):

grub2-efi-x64-2.02-0.64.el7.x86_64
shim-x64-12-1.el7.x86_64

Additional info:

There are at least two ways to solve this:

1) Ensure the RPM packages package /boot/efi and everything underneath it with consistent file modes. For example, ensure that all directories are mode 0755, and all files are mode 0644. This will permit specifying dmask/fmask mount options to match what the RPM database asserts (e.g., dmask=0022,fmask=0133), and thus rpm --verify will not throw errors.

2) Ensure the RPM packages use the %(verify not mode) directive on /boot/efi and everything underneath it, so that rpm --verify will not check the file modes on /boot/efi or anything underneath it.

Of these options, I think option #2 is conceptually cleaner: since there is every expectation that /boot/efi will be mounted as an ESP, the modes on /boot/efi and everything underneath it are irrelevant, and RPM should not attempt to verify them.

I think the only reason to go for option #1 would be to protect naive system administrators from accidentally mounting /boot/efi with insane mask settings (e.g., umask=0000). But since anaconda generates a sane umask (umask=0077), and there's no guarantee that such a system administrator would pay attention to the output of rpm --verify anyway, I don't think this additional protection is worth it.