[Rpm-maint] FSM hooks for rpm plugin
pmatilai at laiskiainen.org
Thu Mar 14 10:54:03 UTC 2013
On 03/13/2013 01:08 PM, Reshetova, Elena wrote:
>>> Do you want to do the changes? I can also try to do it tomorrow if
>>> they aren't objections.
>> I probably should merge (at least some of) the "study" and link count patches
>> first, as those change the landscape quite a bit. I'll try to do that as soon
>> as the caffeine kicks in for good.
> Sure, I will wait for changes.
>> On a somewhat related note, I'm pondering about changing fsm to do staged
>> removals too, ie rename before actually removing. It doesn't make much
>> difference as things are now, but I've also started seriously thinking about
>> changing the fsm to the model we discussed earlier where unpacking and
>> setting >permissions etc is first done for all files, and only if that
>> succeeds completely we actually commit to renaming them all to the final
>> target, and undo the whole lot if anything in unpacking failed.
> I think this would be the safest way not only from security, but also from
> correctness and also makes installation more robust in case of sudden power
> cuts and etc.
Indeed. The way rpm currently behaves on failure is just plain embarrassing.
>> ...which of course would actually fundamentally change the landscape
>> again: if commit is changed to consist only of renaming a file, then "commit"
>> hooks would no longer the right place to do security labeling etc. Argh! :)
>> In that model we'd be back to the "set metadata" hook, or actually two of
>> them to preserve the possibility of doing something after rpm did its own
>> business. >And in that model, both pre and post metadata hooks should get the
>> temp and final path as separate arguments.
> Yeah, but I guess maybe we can first finish with the current system and check
> that it works for whatever test cases we have (I can start using new hooks in
> msm plugin) and then change it when you move rpm to a new fsm model. I think
> this would be a big change for fsm, so won't be possible to do it fast anyway.
Sure, I'm not suggesting delaying everything until I someday get around
to fixing it, just that we could try thinking ahead for that model to
hopefully avoid having to change the plugin interfaces later. I pushed a
bunch of fsm changes yesterday, the two more interesting ones that we
already talked about being:
1) Reflect the hardlink count in st_nlink so the real files vs hardlinks
can be easily detected
2) Set permissions before committing to the rename to final destination.
With 2) in place, we might be able to model the hooks in a way that
doesn't require changing later. The question (again) just is, what the
hooks should actually be.
I think we'd want those pre- and post-commit hooks in any case: for
example a %config versioning system plugin would want to know whether a
file is being replaced and if it actually succeeded. The pre-commit hook
could of course be used for setting additional permissions, content
checking etc as well, but in the alleged new model of unpack + set
permissions on all files first and only then commit, I think one would
want to abort the whole thing as early as possible.
Not that it matters all that much if we really are able to undo the
whole thing. So I guess we'll just go with the pre- and post-commit
hooks for now to be able to move forward with this. At least no-one can
say this hasn't been thoroughly discussed :)
- Panu -
More information about the Rpm-maint