-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Want an option for transient /etc #2868
Comments
Note another example of a file (well a symlink), that may want to be added or unadded to early /etc: This was a feature added to do non-rootfs updates at a very early point in the boot, i.e. a firmware upgrade. Just another feature to consider, even if it clashes, I'm sure we could figure something out. /etc was chosen as a location for the symlink as it's one of the earliest mounted rw persistent directories that exists, maybe it's as simple as moving the location of this symlink or treating it exceptionally somehow like /etc/machine-id or /etc/resolv.conf |
In preparation for support for a transient `/etc`: ostreedev#2868 particularly in combination with composefs. Basically it's just much more elegant if we can directly mount an overlayfs on the *empty* `etc` directory, using `usr/etc` as the lower. In the composefs case, we'd have to mount the composefs overlayfs itself writable (and call `mkdir`) *just* so we can make that empty `etc` directory which is ugly.
Some WIP for this in #2970 |
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
This was fixed by #3062 |
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
For the automotive usecase, and for the general extension of the composefs work (#2867) it would be nice to have a mode where /etc is mounted as an overlayfs on top of /usr/etc from the commit and a tmpfs directory (say in /run). This way you can have a system that is validated by composefs, where you cannot persist system changes between boots.
In theory this should not be very complex, but my initial experiments ran into some issues with selinux contexts which need to be resolved.
In addition, there are some files that we really want to per persist in /etc that are host machine specific. In particular, the
machine-id
file. This would have to be solved by copying in it from some persistent location during early boot.Additionally, and vaguely related:
In the automotive project we are interested in being able to extend the system dynamically, but in a controlled fashion. In particular, we want to install container images and add systemd service files, but only for a trusted set of apps. Such service files would have to be persisted in /etc/systemd/system, but allowing files to be added there is very risky. The plan we have for this is to have a systemd generator that copies these files from a persisted location, after having verified that they are all signed (for example, using fs-verity signatures) against a trusted key.
For full chain of trust, this also needs a container image backend using composefs, which is also in the works.
The text was updated successfully, but these errors were encountered: