[Rpm-maint] FSM hooks for rpm plugin
pmatilai at laiskiainen.org
Sat Mar 16 10:53:46 UTC 2013
On 03/15/2013 12:45 PM, Reshetova, Elena wrote:
> On 03/14/2013 03:01 PM, Reshetova, Elena wrote:
>>> 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 :)
>> I just went through your yesterday's changes. I think it now slowly
>> falls together nicely. I think it is right that we need pre and post
>> fsm hooks because even if we were able to unpack everything and
>> successfully set all permissions on all files in tmp location, it
>> isn't a guarantee that committing the whole thing to the final
>> location would be successful. It is always possible that preserving
>> security labels might fail or anything else might happen. And when you
>> change a fsm model to new one, we can just add a new hook that would
>> be called after each file is unpacked to tpm location: this would be
>> primary hook for setting additional metadata on file and good time to
>> scan the content of a file, too (so that we can revert the whole thing and delete a file if malware is found in it).
>> Yup, and its this part I'm still pondering about: should we just add that post-unpack hook (or whatever its called) already and go with that for SELinux and all from the start, because that's what they really want. That's kinda what the setmetadata hook >idea, but perhaps a more generic name would be appropriate now that it wouldn't be limited to that. Maybe something like file pre- and post-process, which can cover metadata, malware scanning and whatnot, both for install and erase (which needs the >perhaps otherwise unnecessary pre-hook)
> Hm... I guess you are right: even without changing fsm, such hook can be introduced now and started to be used right away. But do you want to have one hook (for install and erase) or two hooks (pre- and post-process)? I think having pre- hook isn’t very beneficial, but post-unpack is the needed one. Maybe we can call it smth like FilePrepare or so to indicate that file is tmp location and hook is called to setup the necessary attributes and check the file?
Hmm, I kinda like that: FilePrepare is generic enough that it can be
used for both installs (ie post create) and erasures (pre remove). Dunno
if its *the* most descriptive name possible but really good names are
annoyingly hard to come by with :) It's good enough for now in any case.
And yeah, having separate pre/post hooks is probably an overkill for
BTW I further hacked fsm yesterday to move the metadata setting out of
fsmCommit() into the main rpmPackageFilesInstall() loop. It doesn't make
much of a difference technically yet, but I think it makes it a bit
easier to think about it as a separate step from commit when it actually
>> The only thing that I can't find so far a usage for pre commit hook
>> for future: it would be kind of called on the same context (file is
>> unpacked in tpm dir) and the future metadata/content screening
>> hook.... One idea can be that for security needs, plugins can actually
>> use pre- and post hooks to verify that permissions were preserved (and
>> set) correctly and abort if they see some mismatch. But maybe this is
>> too paranoid again :)
>> That's perhaps slightly paranoid, yes :) But then its not my job to say what the plugins should be used... for some purpose having yet another layer of verifying might be reasonable.
>> One use-case I see for the pre- and post-commit hooks is a plugin keeping track of config file contents: in pre-commit it would stage the change of content (think of "git apply"), and in post-commit it would either commit or abort (think of "git commit" or >"git reset --hard") depending on whether fsm commit succeeded or not.
> Yes, I think this might be a better use case than a paranoid plugin :) So, then we have 3 hooks: pre- and post- commit and some kind of filePrepare after unpack. I think this should be smth we will be able to leave with for quite a while even when fsm is changed.
Yup, those three hooks are something I think we can reasonably expect to
stay semantically the same no matter how much things change underneath.
That's perhaps been one of the bigger problems in introducing the file
hooks: trying to wedge hooks with sane semantics onto the twisted beast
that fsm was (and of course still is, if to slightly lesser degree) ...
well, fsm fights back with vengeance every step of the way :)
- Panu -
More information about the Rpm-maint