DPS UUID for /etc/ + limit inode types on tmpfs

[NekkoDroid]

The features

1. A new UUID for /etc/ partition (Discoverable Partition Specification)
2. Mount option to limit the allowed inode types for a tmpfs (Kernel Feature)

I don't know if these features would have some existing limitations in implementing them/or I may have overlook something and they might not address what I think they'd do, so I thought I'd first bring them to discussion.

The motivation

On my quest to make the most image based system that can still be comfortably daily driven, my goal is to only have /var/ and /home/ and in /etc/fstab configured mount points read-write, while everything else is read-only by default.

Ideally /etc/ wouldn't even exist and all config is handled by something like systemd-confext, but since /var/s partition UUID depends on the value from /etc/machine-id some location to persistently store configs is needed before /var/ can even be mounted. This would either need to be the / partition or a new /etc/ partition. Preferrably this would be a new /etc/ partition, so that changes can be made to configuration without needing to compromise root read-onlyness, or when something at root needs to be mounted (and a dir needs to be made for it) it doesn't temporarly make /etc/ writable (when systemd-confext doesn't have anything overlayed yet).

With such a /etc/ partition I though: Is there even a need for an actual root partition anymore when all persistent storage already has its own mount point? My though was that the only thing needed is the root directory structure, compatibility symlinks (/bin, /lib, ...) and being able to create mounts for systemd-homed and /etc/fstab, the mounts requiring read-write access to create directories making it impossible to use a pre-created read-only partition without severly restricting where can be mounted. Therefore to my knowledge everything needed would be covered by a tmpfs that limits creating inodes to the type of directories and symlinks, unless I am completely off.

The reason to not allow creating files on root is to minimize the possibility of accidentally creating files at volatile locations.

I thought I'd bring it up here before I make individual issues on the respective repos to see if there might be some early feedback on the broad idea/thought processes.

[poettering]

Our thinking was always that instead of splitting /etc/ out of the root fs, you just split everything else out of the root fs, and keep /etc/ as basically only thing (besids some inodes to overmount as mount points).

The thing is that /etc/fstab is usually the place where further fs are listed to mount, hence it makes sense to have it on the "anchor" mount, i.e. the root fs, rather than on a secondary mount, because that creates the problem how do you configure where /etc/ is to be found?

Hence, I am not convinced this makes sense.

[NekkoDroid]

That reasoning is what I kind of thought was the rational behind it and it mostly makes sense. I already have most of the other locations split out to separate partitions.

My "concern" with the way that would work is that either / and /etc/ are both either read-only or both are read-write and I am looking for an easy/automatic way to have /etc/ read-only, while / is still writable for directories when a new mount location needs to be made (be it manually invoked or automatic with sd-homed).

What would your recommendations/thoughts about this be?

because that creates the problem how do you configure where /etc/ is to be found?

Generally you wouldn't was my thought and it would be specifically for just automounting to the standard location. But I do see how it could be problematic to have this special case where it can't really be configured.

[poettering]

I don't see a reason why "add new mount point to the root dir" should be possible independently of "add new entry to /etc/fstab". Either you allow both or you allow neither. Hence, I am pretty sure it's entirely sufficient if /etc/ and / have the same properties when it comes to immutability.

[NekkoDroid]

I guess you might actually be right on that. I guess I am just too use to manually mounting temporary stuff somehwere in /mnt/ when it could also be mounted somewhere in /run/ or other tmpfs.

Although on the other hand I do intend to use sd-homed's ability to have $HOME on a separate drive, without a spearate /home/ partition, as that would just seem like a waste of space to store an entire partition for just a few mount points that are all created dynamically.

What I basically want to say is: I do agree now that a separate UUID for /etc/ isn't necessary, but the second feature of being able to limit a tmpfs mount to only certain inode types would be useful for /home/ in my case just to limit possible user errors. Or is there some reason that this would be undesirable?