Discussion:
automount EFI system partition to /efi fails
(too old to reply)
Chris Murphy
2018-04-25 00:47:24 UTC
Permalink
Raw Message
https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
*The ESP used for the current boot is automatically mounted to /efi (or
/boot as fallback),*

systemd-238-7.fc28.1.x86_64

I've commented out the /boot/efi entry in /etc/fstab and reboot but the ESP
doesn't get mounted to /efi or /boot or /boot/efi.


Full journal with systemd.log_level=debug.
https://drive.google.com/open?id=1b4Lfd0HurX4Z68T1jAHYMC0wy51tQwtk

I get a couple of confusing items:

[ 3.971099] f28h.local systemd-gpt-auto-generator[476]: /efi already
populated, ignoring.
[ 4.102022] f28h.local audit[476]: AVC avc: denied { read } for
pid=476 comm="systemd-gpt-aut" name="efi" dev="nvme0n1p9" ino=3999777
scontext=system_u:system_r:systemd_gpt_generator_t:s0
tcontext=unconfined_u:object_r:default_t:s0 tclass=dir permissive=0


It's definitely empty. But maybe it's due to the avc. chcon fails to set
the type to systemd_gpt_generator_t which itself gives me an avc.

Apr 24 18:42:49 f28h.local audit[4486]: AVC avc: denied { relabelto } for
pid=4486 comm="chcon" name="efi" dev="nvme0n1p9" ino=3999777
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=system_u:object_r:systemd_gpt_generator_t:s0 tclass=dir
permissive=0


Next


[ 6.291607] f28h.local systemd[715]: Followed symlinks /efi → /efi.
[ 6.291643] f28h.local systemd[715]: Applying namespace mount on /efi
[ 6.291671] f28h.local systemd[715]: Successfully mounted /efi to /efi
[ 6.294820] f28h.local systemd[715]: Remounted /efi read-only.
[ 6.314602] f28h.local systemd[715]: Remounted /sys/firmware/efi/efivars
read-only.
[ 6.316442] f28h.local systemd[724]: Followed symlinks /efi → /efi.
[ 6.316472] f28h.local systemd[724]: Applying namespace mount on /efi
[ 6.316505] f28h.local systemd[724]: Successfully mounted /efi to /efi
[ 6.323415] f28h.local systemd[724]: Remounted /efi read-only.
[ 6.354865] f28h.local systemd[753]: Followed symlinks /efi → /efi.
[ 6.354895] f28h.local systemd[753]: Applying namespace mount on /efi
[ 6.354925] f28h.local systemd[753]: Successfully mounted /efi to /efi
[ 6.381654] f28h.local systemd[753]: Remounted /efi read-only.
[ 6.489023] f28h.local systemd[762]: Remounted /sys/firmware/efi/efivars
read-only.


And some additional repetitions but no avcs. So I'm not sure what the
problem is.




--
Chris Murphy
Zbigniew Jędrzejewski-Szmek
2018-04-25 08:10:17 UTC
Permalink
Raw Message
On Wed, Apr 25, 2018 at 07:48:13AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Apr 24, 2018 at 06:47:24PM -0600, Chris Murphy wrote:
> > https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
> > *The ESP used for the current boot is automatically mounted to /efi (or
> > /boot as fallback),*
> >
> > systemd-238-7.fc28.1.x86_64
> >
> > I've commented out the /boot/efi entry in /etc/fstab and reboot but the ESP
> > doesn't get mounted to /efi or /boot or /boot/efi.
>
> gpt-auto-generator cannot mount anything to a nested directory,
> because when it's running the outer mount (/boot in this case) will
> not be done yet, hence it cannot check if /boot/efi is a directory. So
> by design it will only consider /efi and /boot as the targets.
>
> > Full journal with systemd.log_level=debug.
> > https://drive.google.com/open?id=1b4Lfd0HurX4Z68T1jAHYMC0wy51tQwtk
> >
> > I get a couple of confusing items:
> >
> > [ 3.971099] f28h.local systemd-gpt-auto-generator[476]: /efi already
> > populated, ignoring.
> > [ 4.102022] f28h.local audit[476]: AVC avc: denied { read } for
> > pid=476 comm="systemd-gpt-aut" name="efi" dev="nvme0n1p9" ino=3999777
> > scontext=system_u:system_r:systemd_gpt_generator_t:s0
> > tcontext=unconfined_u:object_r:default_t:s0 tclass=dir permissive=0
> >
> >
> > It's definitely empty. But maybe it's due to the avc. chcon fails to set
> > the type to systemd_gpt_generator_t which itself gives me an avc.
>
> It's possible that this is the cause. From the AVC we don't see the name,
> but we know it's a directory and read() fails on it. Failure to list the
> directory will cause gpt-auto-generator to consider the directory busy,
> which would lead to the "/efi already populated" message.

https://github.com/systemd/systemd/pull/8812 has a patch to improve
logging in this case.

Zbyszek

> > Apr 24 18:42:49 f28h.local audit[4486]: AVC avc: denied { relabelto } for
> > pid=4486 comm="chcon" name="efi" dev="nvme0n1p9" ino=3999777
> > scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > tcontext=system_u:object_r:systemd_gpt_generator_t:s0 tclass=dir
> > permissive=0
> >
> >
> > Next
> >
> >
> > [ 6.291607] f28h.local systemd[715]: Followed symlinks /efi → /efi.
> > [ 6.291643] f28h.local systemd[715]: Applying namespace mount on /efi
> > [ 6.291671] f28h.local systemd[715]: Successfully mounted /efi to /efi
> > [ 6.294820] f28h.local systemd[715]: Remounted /efi read-only.
> > [ 6.314602] f28h.local systemd[715]: Remounted /sys/firmware/efi/efivars
> > read-only.
>
> It looks like /efi does get mounted. What mounted it?
>
> Zbyszek
Lennart Poettering
2018-04-25 09:10:54 UTC
Permalink
Raw Message
On Mi, 25.04.18 07:48, Zbigniew Jędrzejewski-Szmek (***@in.waw.pl) wrote:

> > [ 6.291607] f28h.local systemd[715]: Followed symlinks /efi → /efi.
> > [ 6.291643] f28h.local systemd[715]: Applying namespace mount on /efi
> > [ 6.291671] f28h.local systemd[715]: Successfully mounted /efi to /efi
> > [ 6.294820] f28h.local systemd[715]: Remounted /efi read-only.
> > [ 6.314602] f28h.local systemd[715]: Remounted /sys/firmware/efi/efivars
> > read-only.
>
> It looks like /efi does get mounted. What mounted it?

That's misleading I figure. That message is probably caused by
ProtectSystem=yes or ProtectSystem=full being set for some system
service. In that case systemd will mount /efi and /boot read-only for
the specific service, but leave / writable. And for that to work it
synthesizes a bind mount point for /efi and /boot within the service's
mount namespace, the logging about which you see above. It hence
doesn't mean /efi or /boot is a mount point on the host.

Lennart

--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2018-04-25 10:25:54 UTC
Permalink
Raw Message
On Wed, Apr 25, 2018 at 11:10:54AM +0200, Lennart Poettering wrote:
> On Mi, 25.04.18 07:48, Zbigniew Jędrzejewski-Szmek (***@in.waw.pl) wrote:
>
> > > [ 6.291607] f28h.local systemd[715]: Followed symlinks /efi → /efi.
> > > [ 6.291643] f28h.local systemd[715]: Applying namespace mount on /efi
> > > [ 6.291671] f28h.local systemd[715]: Successfully mounted /efi to /efi
> > > [ 6.294820] f28h.local systemd[715]: Remounted /efi read-only.
> > > [ 6.314602] f28h.local systemd[715]: Remounted /sys/firmware/efi/efivars
> > > read-only.
> >
> > It looks like /efi does get mounted. What mounted it?
>
> That's misleading I figure. That message is probably caused by
> ProtectSystem=yes or ProtectSystem=full being set for some system
> service. In that case systemd will mount /efi and /boot read-only for
> the specific service, but leave / writable. And for that to work it
> synthesizes a bind mount point for /efi and /boot within the service's
> mount namespace, the logging about which you see above. It hence
> doesn't mean /efi or /boot is a mount point on the host.

Even if /efi is empty? We should probably skip the mount point in that
case as a minor optimization.

Zbyszek
Lennart Poettering
2018-04-25 10:57:15 UTC
Permalink
Raw Message
On Mi, 25.04.18 10:25, Zbigniew Jędrzejewski-Szmek (***@in.waw.pl) wrote:

> On Wed, Apr 25, 2018 at 11:10:54AM +0200, Lennart Poettering wrote:
> > On Mi, 25.04.18 07:48, Zbigniew Jędrzejewski-Szmek (***@in.waw.pl) wrote:
> >
> > > > [ 6.291607] f28h.local systemd[715]: Followed symlinks /efi → /efi.
> > > > [ 6.291643] f28h.local systemd[715]: Applying namespace mount on /efi
> > > > [ 6.291671] f28h.local systemd[715]: Successfully mounted /efi to /efi
> > > > [ 6.294820] f28h.local systemd[715]: Remounted /efi read-only.
> > > > [ 6.314602] f28h.local systemd[715]: Remounted /sys/firmware/efi/efivars
> > > > read-only.
> > >
> > > It looks like /efi does get mounted. What mounted it?
> >
> > That's misleading I figure. That message is probably caused by
> > ProtectSystem=yes or ProtectSystem=full being set for some system
> > service. In that case systemd will mount /efi and /boot read-only for
> > the specific service, but leave / writable. And for that to work it
> > synthesizes a bind mount point for /efi and /boot within the service's
> > mount namespace, the logging about which you see above. It hence
> > doesn't mean /efi or /boot is a mount point on the host.
>
> Even if /efi is empty? We should probably skip the mount point in that
> case as a minor optimization.

Yupp, if it exists it's turned into a read-only mount point.

Not sure if it's worth optimising this corner case, in particular as
while the thing might be empty initially it might not be later on, and
hence we should probably protect those future files too.

Lennart

--
Lennart Poettering, Red Hat
Chris Murphy
2018-04-25 19:24:57 UTC
Permalink
Raw Message
What happens if /efi does not yet exist? I created it normally 'sudo
mkdir /efi' before modifying /etc/fstab to comment out /boot/efi line.

So far as I know, installers don't create /efi (Fedora's installer
does not) so that would be a needed feature. And then also things that
modify /boot/efi need to be modified to use /efi instead. Some of this
is abstracted with symlinks, e.g. Fedora uses symlink grub2-efi.cfg ->
../boot/efi/EFI/fedora/grub.cfg which is how grubby modifies it, but
that can be changed to grub2-efi.cfg -> ../efi/EFI/fedora/grub.cfg -
the bigger change is with the bootloader binaries needing updating,
those packages have to know to look at both locations for the
foreseeable future. Not too difficult, just a matter of doing it.


---
Chris Murphy
Chris Murphy
2018-04-25 19:36:22 UTC
Permalink
Raw Message
Also filed an selinux-policy bug to support /efi

https://bugzilla.redhat.com/show_bug.cgi?id=1571962


---
Chris Murphy
Lennart Poettering
2018-04-26 11:23:43 UTC
Permalink
Raw Message
On Mi, 25.04.18 13:24, Chris Murphy (***@colorremedies.com) wrote:

> What happens if /efi does not yet exist? I created it normally 'sudo
> mkdir /efi' before modifying /etc/fstab to comment out /boot/efi
> line.

Nothing. The generator that establishes this automount point becomes a
NOP unless:

1. /efi exists
2. /efi is empty
3. There's no mount listed for it in /etc/fstab

Hence, if you want to make use of the automatic ESP mounting logic,
then simply create /etc and all should be good.

> So far as I know, installers don't create /efi (Fedora's installer
> does not) so that would be a needed feature. And then also things that
> modify /boot/efi need to be modified to use /efi instead. Some of this
> is abstracted with symlinks, e.g. Fedora uses symlink grub2-efi.cfg ->
> ../boot/efi/EFI/fedora/grub.cfg which is how grubby modifies it, but
> that can be changed to grub2-efi.cfg -> ../efi/EFI/fedora/grub.cfg -
> the bigger change is with the bootloader binaries needing updating,
> those packages have to know to look at both locations for the
> foreseeable future. Not too difficult, just a matter of doing it.

The automatic /efi magic is an offer to distributions, that allows
them to remove any kind of mount setup during distro install, and
exposes exceptionally safe access to the ESP (because it is umounted
shortly after every access though still appears mounted
continously). However, it's really just that: an offer. Fedora doesn't
use that by default last time I looked, though I wish it would. I
guess this needs a champion who pushes this through the fedora changes
bureaucracy.

I'd recommend Fedora to create /efi at boot, and then maintain a
compat symlink /boot/efi → ../efi to maintain compatibility with the
status quo ante.

If fedora were to make that change, I figure some RPM postinst script
would have to rearrange things roughly like this:

```sh
sed -i -e '/\/boot\/efi/d' /etc/fstab
mkdir /efi
umount /boot/efi
rmdir /boot/efi
ln -s ../efi /boot/efi
```

Lennart

--
Lennart Poettering, Red Hat
Loading...