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)
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.
- Panu -
_______________________________________________
Rpm-maint mailing list
[email protected]
http://lists.rpm.org/mailman/listinfo/rpm-maint
