Re: Mounting EFI partition: default to `uid=0,gid=0`
Hi,
I will look into this setting. Thanks for pointing this out.
Now, to rewind to the original question, because my use case distracts from my question:
I noticed that the mount-configuration in `/etc/fstab`, by default, relies on an *implicit* assumption for the ownership of the ESP to /boot/efi, i.e. 'root' (uid 0) only because it is executed as part of the boot process.
Is this intentional? (i.e. was this considered?)
I am guessing the answer is 'yes', given that you immediately skip this and focus on pointing out my actions which helped to discover this assumption/implicit behavior. I will consider my question answered then.
Kind regards,
Danny
On Tuesday, 21 November 2023 at 20:56, Steve McIntyre <steve@einval.com> wrote:
>
>
> [ Argh, please turn off the crappy auto-encryption with your
> protonmail setup. It's utterly pointless when discussion is going to
> a mailing list too... ]
>
> Hi Danny,
>
> On Tue, Nov 21, 2023 at 07:20:31PM +0000, Danny van Heumen wrote:
>
> > On Nov 21, 2023, 4:59 PM, Steve McIntyre < steve@einval.com> wrote:
> >
> > > In normal use, the EFI partition isn't mounted by a user. What are
> > > you trying to solve here?
> >
> > I wanted to make the partition user-mountable such that I can mount
> > it before upgrading packages. The partition would not be mounted by
> > default. (\`noauto,users\\`) Then I found out that it defaults to
> > ownership of mounting users, which is not good.
> >
> > As I mentioned previously, I would argue that the ESP should always
> > mount with owner 0, even if my use case/experiment itself is an
> > outlier. I spotted my mistake, but was surprised by how owner is
> > chosen (in such a case).
> >
> > Yes, even when using sudo this shouldn't be a problem, however the
> > behavior does deviate from other filesystems which have their own
> > permission bits therefore have "protection" (maybe a strong word)
> > against this situation.
>
>
> Debian's standard installation setup works here as expected. If you
> want to break that, then I think it's up to you to handle the
> consequences I'm afraid. You're already modified the fstab to do
> what you want, you get to make the other changes you want too. OK?
>
> --
> Steve McIntyre, Cambridge, UK. steve@einval.com
> The two hard things in computing:
> * naming things
> * cache invalidation
> * off-by-one errors -- Stig Sandbeck Mathisen
Reply to: