[Rpm-maint] First attempt for the patch on extending the plugin interface for rpm
pmatilai at laiskiainen.org
Tue Oct 16 11:04:39 UTC 2012
On 10/15/2012 03:18 PM, Reshetova, Elena wrote:
> After reading your responses I think we indeed need to break this patch into
> at least two or three parts. It would help us to concentrate on one set of
> the hooks at the time and integrate them separately in steps.
> You mentioned that pre/post tsm/psm hooks are pretty much fine, so we can
> start from them.
Fine with me.
> I would propose to add to them a security plugin loading
> function and macros.
Obviously there needs to be some way of loading the plugins... What
kinda bothers me here is the notion of "security plugin" - except for
perhaps the signature/conflict hooks, there's nothing inherently
The two immediate candidates *are* security-oriented, but they're very,
very different in what they do and how they affect the system. Eg if you
disable SELinux labeling on a system where SELinux is enabled, you'll
pretty much just shoot yourself in the foot (by ending up with a rather
screwed up system) rather than fundametally bypass system security.
"Transaction plugin" or something to that effect would seem to be more
appropriate as these hooks could be used for all sorts of purposes
(additional logging / interaction with other systems like dbus
notifications for somebody ... whatever).
> Also, if there are no objections I would add here a
> ScriptSetup hook (it is rather simple one and outside of other hooks). This
> can be the first bunch that we can bring into shape to be acceptable for
The script setup hook is fairly obvious too, just forgot to mention it.
The one question with that is (again) the argument(s) it receives:
currently its ARGV_t, but does it actually need the entire argv or would
just the actual executable path suffice for the setup?
Another possibility might be passing an rpmScript "object" (which would
need exporting and probably added interfaces, but that's kinda in the
plans anyway at some point). But perhaps that's best left for later.
> Then after the above is hopefully merged I will start attacking the
> file-related hooks (I have already made a number of changes and will look
> into improving them further based on your comments). And at the end we can
> talk about how to integrate the rest.
> I will post the first bunch shortly if there are no objections.
Feel free to post as many revisions as you want, it tends to be more
productive to discuss actual patches than hand-wavy abstractions :)
> Further comments are inline:
>> Actually, the ability to sanely disable these things from cli and API is in
> practise a hard requirement. The reason is that rpm is used in a large
> variety of situations beyond the basic "system package management"
>> task: creation of chroot (build-)environments that are nothing like what
> the system might be running, install/live images, certain per-user tasks,
> workarounds for weird setups etc. Plus all the things we never even imagined
> - by now I hope to have learned (the hard way) that no matter how unlikely
> it >seems, the unforeseen oddball (yet legal) cases always exist :)
>> I do realize that needs on an embedded / handheld systems can be
> drastically different from a general purpose system. How to support "full
> lockdown" where needed but allow disabling for other uses is something to
> think about.
> Hm.. This isn't easy indeed. Can we make a security plugin a special case
> regarding to the cli? Meaning that if the rpm is compiled with
> "ENFORCE_SECURITY", then it isn't possible to disable the security plugin
> from cli and if loading/expanding of security plugin fails, then rpm stops.
> Providing cli or API option to disable additional security enforced by the
> plugin(s) even if security have been compiled in sounds scary for me....
I dunno... There are soooo many different options and API flags that
affect these things, attempting to enforce things from the inside of rpm
seems hopelessly futile: practically every aspect of rpm's behavior is
overridable via cli, API and configuration. Including the paths where
rpm loads its configuration from. You'd need to have a hard-wired list
of mandatory plugins and their non-macro paths compiled rpm to enforce
anything at all. And even then, if you have cli access as root, what's
to prevent the user from just replacing the executable/libraries with
something that doesn't enforce anything?
The way I see it, the only thing that can enforce the kind of MAC-style
behavior you're after is the kernel:
In terms of SELinux (which is more familiar to me), it might be
something like having rpm confined to very limited read-only
functionality, and the plugin would request a transition to a context
that where installations etc become possible. With that sort of setup,
you can try to disable whatever you want on the cli/api/configuration
but you're unable to *do* anything without having the "security" plugin
loaded, turning the whole picture upside-down. Obviously there would
have to be some kind of (signature?) mechanism of ensuring the plugin is
actually authorized to request the extra privileges.
>> What I was thinking was more in the direction of "if plugin X returned
> failure, should we even call the other hooks" (such as falling back to
> something else if one of the involved filesystem doesn't support feature Y),
> but this is now something that neither the plugin or rpm has any way of
> actually knowing.
>> The point perhaps being, the exact semantics for the plugin hooks needs to
> be far more clearly defined sooner or later.
> I think even if plugin X returns failure on hook Z, we need to call the hook
> Z for all other plugins, because this will make sure that all plugins have
> the same set of hooks that got executed during the rpm transaction. Also, it
> would be up to each plugin to be prepared that rpm transaction can stop and
> fail outside of the plugin (inside rpm itself or inside of other plugins)
> and then be ready that only cleanup hook is called. So, for example, plugin
> might have pre tsm/psm hooks called and they go fine, but then some other
> plugin returns a failure on prepsm hook, so whole transaction goes to
> failure and plugin gets cleanup hook called even if from its point of view
> everything went fine.
Yup. My "issues" here are probably just a matter of adjusting my own
thinking to the different style needed by plugins :)
>> FWIW, I've been considering exporting the fd digest API for quite some
>> time. That stuff probably needs a bit of polishing/sanitizing before
>> exporting, but I'm not at all opposed to doing it.
> Yes, I think this would be good and then it can be cleaner from plugin side
> to get digest calculated.
Ok. I'll try to have a look at it soonish.
>> For now, go for the absolute minimum exposure of rpm "objects". The
>> problem here is different from the other internals (such as fsm in the
>> previous versions) exposure, the issue here is that it exposes a ad-hoc
>> set of things that rpm currently happens to internally use to handle
>> this stuff. Which is not entirely unlike Lucas Arts adventure games of
>> old: you have a rope, two bananas and a fish, and you need to somehow
>> use those to cross the ravine to get the umbrella from the other side
>> that you need to... :)
>> The fact that the hook breaks in rpm >= 4.10 despite arguments remaining
>> the same kinda underlines the issue. Rpm internals are going through
>> some pretty fundamental changes at the moment, and this is one of the
>> places that will hopefully become saner when its all done (my wishful
>> thinking is to have at least the basics around in rpm 4.11 already).
>> When that happens we can export more, but right now its better to keep
>> things to minimum you can get by with.
> Agree, I will take a stronger attempt to reduce the arguments to the actual
> needed once
> for all the file hooks. I guess the conflict one is the most heavy one at
> the moment, so
> I will try to address it properly next time I post the patch for file hooks.
The conflict hook is indeed probably the worst "offender". Of course you
really do want the full information such as in rpmfi to do informed
decisions (at least without having to duplicate all the relevant data
inside plugins, and I dont want to encourage that), the issue here is
just the rpm-internal hysteria with internal/external interfaces,
different representations of packages that are to-be-installed vs the
already installed-ones etc. Lets leave worrying about the conflicts-hook
>> The signature verification hook is another place where some weird
>> internal bits and pieces get passed around. That might be unavoidable,
>> dunno... but then (and I think I've said this before), signature
>> enforcing mechanism should really be in rpm core (and is sorely missed
>> currently). Plugins might further enhance / implement policy around
>> that, or something. Oh and I know this is hand-wavy and vague :-/
> Yes, I think it would be good to think more on this. I understood how you
> would like
> to have it now and agree that this would be an ideal case. I will put this
> on my todo list
> to see how this can be done in a better way.
Ok, cool. The signature enforcement is something I've thought about on
and off for quite some time. I don't recall the specifics offhand, but
IIRC the issues tend to revolve more around legacy expectations of how
things work, both from cli and API-user POV, than the signature
>> What I referred to above is specifically the file conflict resolution
>> thing (and our previous discussion about that). Eg looking at the MSM
>> plugin, AFAICT it can let conflicts pass at this point, yet deny it deep
>> down from inside when the transaction is already in progress. There
>> always will be cases where a failure cannot be detected before actually
>> trying to install (ie, in fsm), but that should be the absolute last
>> resort, not something you'd ever see in "normal" operation.
> Sure, I guess this problem is about the actual hook content, not necessary
> the hook itself. I guess the hook should be redone to not simply log the
> conflict case and decide on it later, but actually decide before starting a
Yes, its indeed what the MSM hook does, rather than the hook itself,
that bothers me. And more generally, the fact that such things become
possible with plugins. I guess its not possible to really prevent, given
sufficiently powerful plugin interface, but if nothing else the
interfaces should encourage the "correct" usage and discourage working
behind rpms back. Whatever that means - I do realize I'm just waving
hands again :)
> I am quite sure I can change it in the plugin itself.
Ok, that'd be good. I was actually wondering why its done the way it is
now - if there is an actual reason (such insufficient information
available at that point), I'd like to understand it.
- Panu -
More information about the Rpm-maint