Add support for wrapping binaries (rpm) #1789
Conversation
|
Also I promise at some point I'll stop collecting WIP PRs and actually finish one or two of them... |
|
Testing this one nicely really wants support for doing a compose and then booting just like sysusers: #1679 (comment) |
cgwalters
force-pushed
the
cli-wrap
branch
2 times, most recently
from
fa36b8e to
fe7da87
Compare
|
☔ The latest upstream changes (presumably 0da9f99) made this pull request unmergeable. Please resolve the merge conflicts. |
|
☔ The latest upstream changes (presumably 83a2674) made this pull request unmergeable. Please resolve the merge conflicts. |
cgwalters
force-pushed
the
cli-wrap
branch
2 times, most recently
from
f745008 to
93a9c6e
Compare
|
@jlebon (or anyone else) any thoughts on this? I think the main thing blocking right now from my PoV is changing the tests to support composing and booting which led me down the rabbit hole of better cosa support for that. |
There was a problem hiding this comment.
@jlebon (or anyone else) any thoughts on this?
I like the containerization idea a lot.
For the CLI switch filtering, let's make sure that the canonical host "query" APIs aren't hitting the scary warning & delay? Otherwise, it can lead to confusing and frustrating UX. The big one is the rpm --query API which I added a comment about below. There's also dracut --list-modules. Haven't checked grubby.
One worry though going down this road is maintenance burden. ISTM like the longer term cleaner approach is to instead integrate rpm-ostree awareness in those projects directly? Not opposed to trying it out though.
So now that we have OSTree layer capabilities in rpm-ostree (coreos/rpm-ostree#1830), I think it makes more sense overall to make the overlay an OSTree layer. The fact that it *is* an RPM, but differs from all the other RPMs in various ways will (and already has) come up multiple times when we talk about signing, changelogs, lockfiles, overrides, etc... (See [1] and [2] for some already filed issues). Switching to an OSTree layer sidesteps many of those issues. Of course, we do lose some things from moving away from RPM: 1. it's harder to determine from where the overlay files come from on a host system (see [3] related to this) 2. invisible to `rpm-ostree db diff` (but then again, the diff we currently get isn't helpful) 3. not possible to issue an advisory for it to be consumed like the rest of the advisories (though with the current approach, making use of this without going through Bodhi would've required some non-trivial amount of work too) Overall though, I think those are things we could (and should strive to) fix in rpm-ostree rather than avoiding layers entirely. [1] coreos#544 [2] coreos#553 (comment) [3] coreos/rpm-ostree#1789
So now that we have OSTree layer capabilities in rpm-ostree (coreos/rpm-ostree#1830), I think it makes more sense overall to make the overlay an OSTree layer. The fact that it *is* an RPM, but differs from all the other RPMs in various ways will (and already has) come up multiple times when we talk about signing, changelogs, lockfiles, overrides, etc... (See [1] and [2] for some already filed issues). Switching to an OSTree layer sidesteps many of those issues. Of course, we do lose some things from moving away from RPM: 1. it's harder to determine from where the overlay files come from on a host system (see [3] related to this) 2. invisible to `rpm-ostree db diff` (but then again, the diff we currently get isn't helpful) 3. not possible to issue an advisory for it to be consumed like the rest of the advisories (though with the current approach, making use of this without going through Bodhi would've required some non-trivial amount of work too) Overall though, I think those are things we could (and should strive to) fix in rpm-ostree rather than avoiding layers entirely. [1] coreos#544 [2] coreos#553 (comment) [3] coreos/rpm-ostree#1789
So now that we have OSTree layer capabilities in rpm-ostree (coreos/rpm-ostree#1830), I think it makes more sense overall to make the overlay an OSTree layer. The fact that it *is* an RPM, but differs from all the other RPMs in various ways will (and already has) come up multiple times when we talk about signing, changelogs, lockfiles, overrides, etc... (See [1] and [2] for some already filed issues). Switching to an OSTree layer sidesteps many of those issues. Of course, we do lose some things from moving away from RPM: 1. it's harder to determine from where the overlay files come from on a host system (see [3] related to this) 2. invisible to `rpm-ostree db diff` (but then again, the diff we currently get isn't helpful) 3. not possible to issue an advisory for it to be consumed like the rest of the advisories (though with the current approach, making use of this without going through Bodhi would've required some non-trivial amount of work too) Overall though, I think those are things we could (and should strive to) fix in rpm-ostree rather than avoiding layers entirely. [1] #544 [2] #553 (comment) [3] coreos/rpm-ostree#1789
|
☔ The latest upstream changes (presumably b381e02) made this pull request unmergeable. Please resolve the merge conflicts. |
cgwalters
force-pushed
the
cli-wrap
branch
2 times, most recently
from
9d0a79c to
c13ce60
Compare
|
☔ The latest upstream changes (presumably c279f92) made this pull request unmergeable. Please resolve the merge conflicts. |
|
☔ The latest upstream changes (presumably 553be6e) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Any further comments on this? |
|
Any thoughts on
? |
That was rejected for RPM: |
|
/test sanity |
There was a problem hiding this comment.
The code itself looks reasonable to me, though part of me still feels a bit uneasy about hijacking those well-known binaries. Overall, I still think a more sustainable approach is integrating this logic directly in the various upstream projects. There was a suggestion in that rpm patch there for example to implement this as a plugin instead.
Another parallel path is continuing the work on making immutable more parts of the filesystem so that even if an app isn't "OSTree-aware", it still can't really do much harm.
That said, I'm not totally against this and open to experimenting with it and seeing how it feels. (Though would definitely want to get more input from others before e.g. turning this on in FCOS.)
Right, that's an important part of this - it's not on by default yet. |
The thing particularly for rpm is...we already have a project binding rpm and ostree - this one. Having an RPM plugin that called into either ostree or rpm-ostree makes everything circular. One idea I did have later is it could make a lot of sense to do this type of thing for the traditional |
cgwalters
force-pushed
the
cli-wrap
branch
6 times, most recently
from
3aec01d to
d45f12b
Compare
We need to be friendlier to people who are transitioning from "traditional" yum managed systems. This patchset starts to lay out the groundwork for supporting "intercepting" binaries that are in the tree. For backwards compatibility, this feature is disabled by default, to enable it, one can add `cliwrap: true` to the manifest. To start with for example, we wrap `/usr/bin/rpm` and cause it to drop privileges. This way it can't corrupt anything; we're not just relying on the read-only bind mount. For example nothing will accidentally get written to `/var/lib/rpm`. Now a tricky thing with this one is we *do* want it to write if we're in an unlocked state. There are various other examples of binaries we want to intercept, among them: - `grubby` -> `rpm-ostree kargs` - `dracut` -> `rpm-ostree initramfs` - `yum` -> well...we'll talk about that later
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, jlebon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This functionality has been around for quite a while in rpm-ostree but I'm not aware of anyone using it. I'd like to turn it on here so we can gain the benefits, which right now are better protection against non-ostree-aware commands run as root (`rpm` and `dracut` namely). A bit more in coreos/rpm-ostree#1789
|
Also note to self; we should add support for intercepting at least |
This functionality has been around for quite a while in rpm-ostree but I'm not aware of anyone using it. I'd like to turn it on here so we can gain the benefits, which right now are better protection against non-ostree-aware commands run as root (`rpm` and `dracut` namely). A bit more in coreos/rpm-ostree#1789
This functionality has been around for quite a while in rpm-ostree but I'm not aware of anyone using it. I'd like to turn it on here so we can gain the benefits, which right now are better protection against non-ostree-aware commands run as root (`rpm` and `dracut` namely). A bit more in coreos/rpm-ostree#1789
We need to be friendlier to people who are transitioning from
"traditional" yum managed systems. This patchset starts to lay
out the groundwork for supporting "intercepting" binaries that
are in the tree.
To start with for example, we wrap
/usr/bin/rpmand cause itto drop privileges. This way it can't corrupt anything; we're
not just relying on the read-only bind mount. For example nothing
will accidentally get written to
/var/lib/rpm.Now a tricky thing with this one is we do want it to write if
we're in an unlocked state.
There are tons of other examples of binaries we want to intercept,
among them:
grubby->rpm-ostree kargsdracut->rpm-ostree initramfsyum-> well...we'll talk about that later