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 <st...@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 < st...@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. st...@einval.com > The two hard things in computing: > * naming things > * cache invalidation > * off-by-one errors -- Stig Sandbeck Mathisen
