Hi,

I recently discovered that `/boot/efi`, being a FAT parition, is mounted with an implicit owner and group, because FAT cannot store permissions. For the default use case, `/boot/efi` is mounted automatically during boot, so there is little risk. With
diffirent mount options, this may become an issue.

Was it ever considered to add `uid=0,gid=0` as default mount options for the EFI System Partition (ESP)?

Kind regards,
Danny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 09/11/2023 at 17:36, Danny van Heumen wrote:

I recently discovered that `/boot/efi`, being a FAT parition, is mounted with an implicit owner and group, because FAT cannot store permissions. For the default use case, `/boot/efi` is mounted automatically during boot, so there is little risk. With

diffirent mount options, this may become an issue.

Was it ever considered to add `uid=0,gid=0` as default mount options for the EFI System Partition (ESP)?

Which use cases would this be useful for ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Resending, as I forgot to reply to the list. Response in line.


On Thursday, 9 November 2023 at 20:52, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

Hi,

On 09/11/2023 at 17:36, Danny van Heumen wrote:

I recently discovered that `/boot/efi`, being a FAT parition, is mounted with an implicit owner and group, because FAT cannot store permissions. For the default use case, `/boot/efi` is mounted automatically during boot, so there is little risk. With

diffirent mount options, this may become an issue.

Was it ever considered to add `uid=0,gid=0` as default mount options for the EFI System Partition (ESP)?

I would argue that this should be independent of use case, that is you would want to ensure the ESP is always accessed as root. (Same as for example the `umask=0077` setting that I think is already part of the install.)
Apart from that, I was experimenting with having /boot not auto-mounted, but only mounted manually when performing system updates.

Which use cases would this be useful for ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Nov 21, 2023 at 03:16:42PM +0000, Danny van Heumen wrote:

Hi,

AFAICT, there was no follow-up to this. Does this mean that it is
preferred that ownership is determined solely by the user who mounts
the EFI partition?

In normal use, the EFI partition isn't mounted by a user. What are you
trying to solve here?

--
Steve McIntyre, Cambridge, UK. steve@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

AFAICT, there was no follow-up to this. Does this mean that it is preferred that ownership is determined solely by the user who mounts the EFI partition?

Regards,
Danny



On Friday, 10 November 2023 at 03:07, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi,

Resending, as I forgot to reply to the list. Response in line.

On Thursday, 9 November 2023 at 20:52, Pascal Hambourg pascal@plouf.fr.eu.org wrote:

Hi,

On 09/11/2023 at 17:36, Danny van Heumen wrote:

I recently discovered that `/boot/efi`, being a FAT parition, is mounted with an implicit owner and group, because FAT cannot store permissions. For the default use case, `/boot/efi` is mounted automatically during boot, so there is little risk.

With diffirent mount options, this may become an issue.

Was it ever considered to add `uid=0,gid=0` as default mount options for the EFI System Partition (ESP)?

I would argue that this should be independent of use case, that is you would want to ensure the ESP is always accessed as root. (Same as for example the `umask=0077` setting that I think is already part of the install.)
Apart from that, I was experimenting with having /boot not auto-mounted, but only mounted manually when performing system updates.

Which use cases would this be useful for ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[ 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.

SGksIHNlZSBpbi1saW5lLgoKLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQpPbiBO b3YgMjEsIDIwMjMsIDQ6NTnigK9QTSwgU3RldmUgTWNJbnR5cmUgPCBzdGV2ZUBlaW52YWwuY29t PiB3cm90ZToKT24gVHVlLCBOb3YgMjEsIDIwMjMgYXQgMDM6MTY6NDJQTSArMDAwMCwgRGFubnkg dmFuIEhldW1lbiB3cm90ZTogPkhpLCA+ID5BRkFJQ1QsIHRoZXJlIHdhcyBubyBmb2xsb3ctdXAg dG8gdGhpcy4gRG9lcyB0aGlzIG1lYW4gdGhhdCBpdCBpcyA+cHJlZmVycmVkIHRoYXQgb3duZXJz aGlwIGlzIGRldGVybWluZWQgc29sZWx5IGJ5IHRoZSB1c2VyIHdobyBtb3VudHMgPnRoZSBFRkkg cGFydGl0aW9uPyBJbiBub3JtYWwgdXNlLCB0aGUgRUZJIHBhcnRpdGlvbiBpc24ndCBtb3VudGVk IGJ5IGEgdXNlci4gV2hhdCBhcmUgeW91IHRyeWluZyB0byBzb2x2ZSBoZXJlPwoKSSB3YW50ZWQg dG8gbWFrZSB0aGUgcGFydGl0aW9uIHVzZXItbW91bnRhYmxlIHN1Y2ggdGhhdCBJIGNhbiBtb3Vu dCBpdCBiZWZvcmUgdXBncmFkaW5nIHBhY2thZ2VzLiBUaGUgcGFydGl0aW9uIHdvdWxkIG5vdCBi ZSBtb3VudGVkIGJ5IGRlZmF1bHQuIChgbm9hdXRvLHVzZXJzYCkgVGhlbiBJIGZvdW5kIG91dCB0 aGF0IGl0IGRlZmF1bHRzIHRvIG93bmVyc2hpcCBvZiBtb3VudGluZyB1c2Vycywgd2hpY2ggaXMg bm90IGdvb2QuCgpBcyBJIG1lbnRpb25lZCBwcmV2aW91c2x5LCBJIHdvdWxkIGFyZ3VlIHRoYXQg dGhlIEVTUCBzaG91bGQgYWx3YXlzIG1vdW50IHdpdGggb3duZXIgMCwgZXZlbiBpZiBteSB1c2Ug Y2FzZS9leHBlcmltZW50IGl0c2VsZiBpcyBhbiBvdXRsaWVyLiBJIHNwb3R0ZWQgbXkgbWlzdGFr ZSwgYnV0IHdhcyBzdXJwcmlzZWQgYnkgaG93IG93bmVyIGlzIGNob3NlbiAoaW4gc3VjaCBhIGNh c2UpLgoKWWVzLCBldmVuIHdoZW4gdXNpbmcgc3VkbyB0aGlzIHNob3VsZG4ndCBiZSBhIHByb2Js ZW0sIGhvd2V2ZXIgdGhlIGJlaGF2aW9yIGRvZXMgZGV2aWF0ZSBmcm9tIG90aGVyIGZpbGVzeXN0 ZW1zIHdoaWNoIGhhdmUgdGhlaXIgb3duIHBlcm1pc3Npb24gYml0cyB0aGVyZWZvcmUgaGF2ZSAi cHJvdGVjdGlvbiIgKG1heWJlIGEgc3Ryb25nIHdvcmQpIGFnYWluc3QgdGhpcyBzaXR1YXRpb24u CgotLSBTdGV2ZSBNY0ludHlyZSwgQ2FtYnJpZGdlLCBVSy4gc3RldmVAZWludmFsLmNvbSA8IEFh cmR2YXJrPiBJIGRpc2xpa2UgQysrIHRvIHN0YXJ0IHdpdGguIEMrKzExIGp1c3Qgc2VlbXMgdG8g YmUgaGFuZGluZyByb3BlLWNyZWF0aW5nIGZhY3RvcmllcyBmb3IgdXNlcnMgdG8gaGFuZyBtdWx0 aXBsZSBpbnN0YW5jZXMgb2YgdGhlbXNlbHZlcy4=

SGksIHNlZSBpbi1saW5lLjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0t LTxicj5PbiBOb3YgMjEsIDIwMjMsIDQ6NTnigK9QTSwgU3RldmUgTWNJbnR5cmUgJmx0OyBzdGV2 ZUBlaW52YWwuY29tJmd0OyB3cm90ZTo8YnI+T24gVHVlLCBOb3YgMjEsIDIwMjMgYXQgMDM6MTY6 NDJQTSArMDAwMCwgRGFubnkgdmFuIEhldW1lbiB3cm90ZTogJmd0O0hpLCAmZ3Q7ICZndDtBRkFJ Q1QsIHRoZXJlIHdhcyBubyBmb2xsb3ctdXAgdG8gdGhpcy4gRG9lcyB0aGlzIG1lYW4gdGhhdCBp dCBpcyAmZ3Q7cHJlZmVycmVkIHRoYXQgb3duZXJzaGlwIGlzIGRldGVybWluZWQgc29sZWx5IGJ5 IHRoZSB1c2VyIHdobyBtb3VudHMgJmd0O3RoZSBFRkkgcGFydGl0aW9uPyBJbiBub3JtYWwgdXNl LCB0aGUgRUZJIHBhcnRpdGlvbiBpc24ndCBtb3VudGVkIGJ5IGEgdXNlci4gV2hhdCBhcmUgeW91 IHRyeWluZyB0byBzb2x2ZSBoZXJlPzxicj48YnI+PGJyPkkgd2FudGVkIHRvIG1ha2UgdGhlIHBh cnRpdGlvbiB1c2VyLW1vdW50YWJsZSBzdWNoIHRoYXQgSSBjYW4gbW91bnQgaXQgYmVmb3JlIHVw Z3JhZGluZyBwYWNrYWdlcy4gVGhlIHBhcnRpdGlvbiB3b3VsZCBub3QgYmUgbW91bnRlZCBieSBk ZWZhdWx0LiAoYG5vYXV0byx1c2Vyc2ApIFRoZW4gSSBmb3VuZCBvdXQgdGhhdCBpdCBkZWZhdWx0 cyB0byBvd25lcnNoaXAgb2YgbW91bnRpbmcgdXNlcnMsIHdoaWNoIGlzIG5vdCBnb29kLjxicj48 YnI+QXMgSSBtZW50aW9uZWQgcHJldmlvdXNseSwgSSB3b3VsZCBhcmd1ZSB0aGF0IHRoZSBFU1Ag c2hvdWxkIGFsd2F5cyBtb3VudCB3aXRoIG93bmVyIDAsIGV2ZW4gaWYgbXkgdXNlIGNhc2UvZXhw ZXJpbWVudCBpdHNlbGYgaXMgYW4gb3V0bGllci4gSSBzcG90dGVkIG15IG1pc3Rha2UsIGJ1dCB3 YXMgc3VycHJpc2VkIGJ5IGhvdyBvd25lciBpcyBjaG9zZW4gKGluIHN1Y2ggYSBjYXNlKS48YnI+ PGJyPlllcywgZXZlbiB3aGVuIHVzaW5nIHN1ZG8gdGhpcyBzaG91bGRuJ3QgYmUgYSBwcm9ibGVt LCBob3dldmVyIHRoZSBiZWhhdmlvciBkb2VzIGRldmlhdGUgZnJvbSBvdGhlciBmaWxlc3lzdGVt cyB3aGljaCBoYXZlIHRoZWlyIG93biBwZXJtaXNzaW9uIGJpdHMgdGhlcmVmb3JlIGhhdmUgInBy b3RlY3Rpb24iIChtYXliZSBhIHN0cm9uZyB3b3JkKSBhZ2FpbnN0IHRoaXMgc2l0dWF0aW9uLjxi cj48YnI+PGJyPjxicj4gLS0gU3RldmUgTWNJbnR5cmUsIENhbWJyaWRnZSwgVUsuIHN0ZXZlQGVp bnZhbC5jb20gJmx0OyBBYXJkdmFyayZndDsgSSBkaXNsaWtlIEMrKyB0byBzdGFydCB3aXRoLiBD KysxMSBqdXN0IHNlZW1zIHRvIGJlIGhhbmRpbmcgcm9wZS1jcmVhdGluZyBmYWN0b3JpZXMgZm9y IHVzZXJzIHRvIGhhbmcgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZW1zZWx2ZXMuIDxicj4=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/11/2023 at 21:35, Danny van Heumen wrote:

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.

There is no implicit assumption. The default mount options set up by the installer command that the ESP is automatically mounted at startup,
resulting in root ownership. There is no need to add uid and gid mount
options.

I agree with Steve: if *you* choose to change the default mount options
with "noauto,users", *you* should deal with the consequences and add
other mount options if needed.

But I believe that your use case is wrong anyway: upgrading packages
requires root privileges so mounting the ESP as a normal user should not
be needed. Instead you may use dpkg's pre-invoke and post-invoke options
or apt's Pre-Invoke and Post-Invoke options to mount and unmount the
ESP, like what can be done to remount /usr read-write during package
upgrades on systems where it is mounted read-only by default.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 21 Nov 2023 22:12:31 +0100
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
I' m afraid I have to read much more about d-i
Especially partitioning.
But where to start?
Ciao

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22/11/2023 at 00:54, yxcv@vienna.at wrote:

I' m afraid I have to read much more about d-i
Especially partitioning.
But where to start?

The debian-installer package contains some documentation (maybe
incomplete and outdated) about partman, the d-i partitioning tool.
But I do not see the relationship with this discussion.

The script fstab.d/efi in installer udeb package partman-efi writes

UUID=xxxx-xxxx /boot/efi vfat umask=0077 0 1

to the target /etc/fstab. It means that the ESP is automatically mounted
at startup and cannot be mounted by a regular user, so the default
ownership is root:root and there is no need to force uid=0,gid=0.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)