On 1/11/22 17:18, Colin Walters wrote:
On Tue, Jan 11, 2022, at 4:00 AM, Panu Matilainen wrote:
> The point was though, that the rpmdb is not at all the only data of this
> kind and so having a dedicated home makes sense.
You mentioned dnf/yum/PackageKit data; there's two kinds of that. One is e.g.
/var/cache/dnf which does *not* move. It's just a cache. (Now there is this whole
other very interesting thread around "why don't we include a cache of the rpm-md
inside e.g. ostree or container images? And the reason why not is we don't want to
have to respin all images every time a package not in the image changes)
dnf does have its own outside-of-rpm state database in /var/lib/dnf which is closer to
this. The situation with that is messier. AIUI this proposal so far is not calling for
moving this. Where it lives and how it's versioned has strong implications for the
people who want to support snapshot/rollback. But it's not relevant for rpm-ostree,
which does not use this part of libdnf. We maintain our own little "state file"
- for lots more detail on this, see
https://github.com/coreos/rpm-ostree/issues/2326
(And it's important to note that rpm-ostree's origin file has almost nothing
*unless* one explicitly engages client-side layering/overrides)
> For one, /state (or whatever toplevel directory) allows for the fact
> that there are write-operations to rpmdb that do not touch any external
> files while maintaining read-only /usr. Such as rpmdb --rebuilddb,
`rpmdb --rebuilddb` is basically about supporting switching from e.g. bdb to sqlite,
right?
On the rpm-ostree side at least, the default format comes from the base image;
there's no reason to directly support `rpmdb --rebuilddb` as something any normal user
or admin would need.
No, it's a database maintenance/repair operation. Converting between
formats is merely a convenient side-effect.
> or rpm --import.
OK yes, this (along with rpms that install into /opt as you mentioned) are I think the
biggest examples of "rpmdb has stuff not about /usr".
rpm --import actually encapsulates really well all the problems and benefits with
everything we're trying to do. I have a big related blurb here
https://github.com/rpm-software-management/libdnf/issues/43
But as I understand it, the creation of /etc/pki/rpm-gpg was at least partially motivated
by the fact that in the traditional RPM model, the fact that GPG keys are stored in the
rpmdb meant there was no way to update them "in band" of a default rpm
operation. Today Fedora ships these GPG keys as an RPM which hence contain files, and
when you type `yum upgrade` (or rpm-ostree upgrade) you get updates to those files, the
same as other files. Now, as noted in the issue PackageKit (whose code was the precursor
to libdnf, which has the code that rpm-ostree uses but AFAIK still not current dnf which
has this logic in Python) auto-imports all of them. I am not completely sure how updating
the rpmdb with new e.g. Fedora GPG key works. It might be part of system-upgrade or
something?
And then this all relates to a higher level goal we have with "image based
updates", which is avoiding (or minimizing as much as possible) per-system hysteresis
or "unmanaged state", particularly opaque (hard to see/diagnose/inspect) state.
This set of trusted GPG keys stored in the rpmdb is both. The set of keys will just keep
growing across in-place upgrades, depending on the initial Fedora version installed. And
wh And this is security-relevant state, it's the set of trusted keys for RPM. Now, I
am sure a number of sysadmins do understand that the rpmdb contains GPG keys. I'd bet
a whole lot don't. I definitely think that it's confusing to have both
/etc/pki/rpm-gpg *and* keys stored in the rpmdb. Of the two, I think the former - i.e.
text files one can edit with standard tools - is much easier to understand and work with.
It's also already in a place that is designed for users to edit in `/etc`.
So by moving the rpmdb to /usr, it's basically saying that `rpm --import` should
change.
This doesn't seem to be documented as a dependency of this move...
That said, this design could also clearly use some "systemd style" config
model. ostree already supports /usr/share/ostree/trusted.gpg.d which is designed for keys
shipped by the OS vendor. But, what's really tricky about this is we want to support
in-place updates from previous versions (i.e. at least N-1), but hopefully not too old
versions. Well, this is leading to a tangent so I'll cut off this sub-thread.
The TL;DR for me is: I think everyone agrees that moving the rpmdb as it is today to /usr
is not 100% a perfect fit. But it's a ~90% fit - almost all the raw data is just
headers which are clearly immutable data generated elsewhere. And by making this change,
we're basically saying we'll fix the remaining 10% of cases.
Note for the people who are trying to do "client side snapshot/rollback" (i.e.
the people whose names are attached to the Change), the rpmdb is still mutable by default.
And I think their idea is is that by doing a "snapshot, then upgrade in place via
traditional rpm/yum methods" approach, the blast radius is then contained to what
happens on explicit rollback. And that's then very limited to e.g. "I wanted to
add a 3rd party RPM and did `rpm --import` to trust their key and then rolled back and
lost that change" which is clearly not a big deal.
For rpm-ostree's "image based" updates model, to avoid hysteresis we always
construct a *new* root (just hardlinked) so any manual outside-of-rpm-ostree's control
changes to `/usr` will always be thrown away, and that's why it's read-only. So
having `rpm --import` fail is intentional today.
But, I hope we can get agreement about something like having `rpm --import` write to
`/etc/pki/rpm-gpg` and dropping gpg keys from the rpmdb.
Rpm actually supports a keyring from the fs since 4.6 I think, it's just
not integrated with --import and doesn't play that well along with the
rest of the ecosystem because everything expects those gpg-pubkey
"packages". We had bugs filed because somebody tried to use the fs-based
thing but yum broke up.
The problem with fs based keyring is that packages can drop arbitrary
unrelated keys in there, combined with the rpm model of imported ==
trusted. The trust aspect would have to be maintained in a place not
directly accessible to packages.
That imported == trusted implication is of course a long-standing flaw
in rpm but difficult to change because of all the assumptions that have
been built around it. Everybody (me included) loves to hate the
gpg-pubkey headers as we know them, but rpmdb as a keyring storage does
make sense. I mean, rpmdb is data which rpm knows, and is free to store
whatever it wishes there. Do understand that Fedora or anybody else
moving it to /usr will not prevent rpm from adding more features that
may need to modify it to store further data. So while it may seem "okay"
now, it may as well not be that way in the future.
- Panu -
- Panu -