Bootctl[2553]: ! Mount point '/efi' which backs the random seed file is world accessible, which is a security hole!

Ask Fedora
, , ,
1

I just noticed this in the journal. You’d think it would be easy to fix, but for some reason, mount seems to be ignoring every option I pass it for /efi. That’s really weird.

I checked my laptop, and it has options umask=0077,shortnames=winnt, and those seem to work on that system. But, those options don’t have any affect on this system. I’m completely confused.

I think there may be something wrong with the partition, but there aren’t any errors during mount that suggest it. When I fsck.vfat it, it says that the boot sector and the backup disagree. I let fsck fix it, but it it just comes back when I mount and unmount the fileystem again.

2

Is it bind mounted somewhere else (e.g. /boot) such that you need to unmount both places first?

Also, you need to run sudo systemctl daemon-reload after editing /etc/fstab.

3

Ah, good questions. No, it’s not bind mounted. I used to do that, but I have no /boot anymore.

Good point. Fortunately, systemctl reminds you to daemon-reload, so i did remember to do that.

It fixed itself after a reboot, though! I set the fstab mount options on the system that was generating that error to the same value as the system that wasn’t generating that error and rebooted. Now the mount options are correct and the error didn’t recur. It seems like /efi might be treated specially, somehow? Maybe efivars has something to do with it?

(Oh, BTW, I wrote the wrong thing above, originally. On the system that didn’t have the error, the fstab mount options for /efi were umask=0077,shrotnames=winnt. The mount option was defaults on the system that had the errors. Sorry for the confusion.)

1 Like
4

I think I encountered something similar once and I just instinctually rebooted the system and never thought anything more about it. I have a hunch/suspicion that the ESP might still be mounted in a hidden namespace somewhere. I’m not sure how to go about confirming that though. Maybe it would show in /proc/mounts if it were mounted in another namespace?

Edit: If it happens again, maybe try this: linux - How do I list the mounts of all namespaces? - Server Fault

1 Like
5

Interesting. I’ve been working in UNIX/Linux for 30 years and I don’t think I’ve heard of lsns before. …Ah, containers. Okay. Cool.

At present, I only see /efi & /sys/firmware/efi/efivars in the mnt namespaces of all processes. But, it is interesting that /efi doesn’t have the same mount options in of the process namespaces, while efivars does. Looks like there are just a hand full of processes with /efi in their namespace:

  • several instances of xdg-dbus-proxy in which /efi is mounted ro,nosuid,nodev
  • gnome-keyring-daemon in which /efi is mounted rw
  • deluged in which /efi is mounted rw

All other mount options are the same between all namespaces.

Is it weird that deluged has that in it’s namespace?

I’m glad I fixed it, I guess. Thanks for your help.

6

I know what you mean. My foray into Linux didn’t really start until '98, but I’m frequently surprised by what I find lurking under the hood as well. :slight_smile:

It is this that I’ve heard rumors and whispers about and which I’m wondering if might be the culprit in this case:

But it’s probably just my paranoia. :slight_smile:

7

Yeah, totally could be that. Or I did it. I converted this system from GRUB to systemd-boot manually. I probably just didn’t know there should be special mount options and set it to ‘defaults’, assuming that was safe. I proly thought I was done with the tutorial I was using and missed the last step or something. :frowning: Thanks again.

8

I know how vfat works, though, so it was just my mistake not thinking it through. I guess I didn’t think anything of it because the default owner is root:root, and I didn’t think anything bad could happen with just read access. But, that’s clearly wrong. I like EFI better than GRUB, but I used to know GRUB way better than I know EFI.

1 Like