conf: Add bootc_unsafe_paths

[evan-goode]

Adds the bootc_unsafe_paths configuration option which can be configured by adding .conf files to the drop-in directory /etc/dnf/bootc-unsafe-paths.d, similar to /etc/dnf/protected.d. Distributions will be able to add paths which are not recommended to be modified at runtime on bootc systems, e.g. /etc/pam.d.

Also bump libdnf version to 0.75.0.

For rpm-software-management/dnf#2199.

[cgwalters]

Why not something generic like locked_paths or protected_paths etc.?

There are other image-based update systems out there, and I could imagine wanting something like this even for a package-based system. (e.g. a subdirectory that should only be writable by an ansible playbook or whatever)

[evan-goode]

I agree, I would like to keep the option name generic if we can. bootc_unsafe_paths would be the first addition of a "bootc"-named option in the DNF API/CLI.

But that being said, we want the logic here to only apply for "bootc transactions". If you're running DNF at image build time, FROM a bootc base image with files in /etc/dnf/bootc-unsafe-paths.d, the unsafe paths should still be writable without any special DNF arguments. Likewise, on a booted bootc system, the protections should not apply when installing to an installroot. I don't think protected_paths makes it clear enough that it only applies to bootc systems (although otherwise it would be my preference).

We use "bootc" language in our docs and CLI output already so it seems more appropriate in an option name than "ostree" or "image mode".

We could call it transient_protected_paths, but I'm pretty sure we want this for --persist too.

If we wanted to make the path protection option be useful generally outside bootc systems, we could add a second option like path_protection: strict|auto|no. path_protection=strict would enable it for all transactions, auto (the default) would be for only bootc transactions (and possibly other situations we deem to want these protections? this is sort of like persistence=auto), and no would disable it entirely. Then that gives us our "I know what I'm doing" flag to disable the protections: --setopt=path_protection=no.

[cgwalters]

Actually how about simply basing it off detecting that /usr is on a distinct filesystem from other target paths? It could be allow_filesystem_skew or something?

[evan-goode]

Perhaps, yes, maybe DNF should be aware of how the mounts are actually set up. For example, how does this play with bootc's etc.transient or root.transient?: https://ostreedev.github.io/ostree/man/ostree-prepare-root.html? If we do dnf4 reinstall authselect-libs --transient and etc.transient is enabled, then we don't care if /etc/pam.d/* is modified since etc is transient and will not drift w.r.t. /usr on reboot.

On the other hand, it's common for different paths in the FHS to be on different filesystems. It's sometimes recommended to place /var on a separate partition for example. So we can't naively look at the mount table and assume that drift will occur if paths are on separate filesystems. We may need some additional coupling with bootc/OSTree.

[cgwalters]

Good point! A few thoughts here:

• A general issue here is that there's a lot of usage of overlayfs (beyond just what ostree does), a composefs is an overlayfs, plus systemd-sysext is overlayfs, plus podman containers are overlayfs
• But we could make the overlayfs mount source be something meaningful (as it is for composefs where source=composefs...say for the /etc transient case we could make it bootc-etc-transient
• But we can definitely also add some sort of API to detect this in bootc, xref feat(edit): configure /usr overlay bootc-dev/bootc#1258 - and we'd extend the root.transient with this

@jmarrero also suggests one approach here is to reconcile on shutdown (or on reboot) by detecting when we had transient overlay packages and undoing their changes to persistent volumes

[evan-goode]

But we could make the overlayfs mount source be something meaningful (as it is for composefs where source=composefs...say for the /etc transient case we could make it bootc-etc-transient

Per the meeting earlier I think this would work for DNF. IIUC if the bootc transient overlays all had the source "bootc-transient" then we could detect "are changes to $path going away on reboot?" with [ "$(findmnt -nvo SOURCE -T "$path")" = bootc-transient ]

But until that's ready we can proceed with this "unsafe path" warning and keep assuming that /etc and /usr will always drift. How about we forget path_protection=on|auto|off and call the paths option usr_drift_protected_paths? This would be a list of paths that "are known to cause problems when their contents drift with respect to /usr".

[kontura]

I am not that familiar with bootc but the name usr_drift_protected_paths sounds good to me assuming there are no plans to extend the overlay beyond /usr.

[kontura]

Tests pass locally.
Thank you