[Rpm-maint] FSM hooks for rpm plugin

Panu Matilainen pmatilai at laiskiainen.org
Wed Mar 6 07:53:54 UTC 2013


On 03/04/2013 10:56 AM, Reshetova, Elena wrote:
>> Looking at this, I just realized that rpm is currently doing chmod(),
>> chown() and all for each hardlink it creates, which just doesn't make
>> sense because ... by the very definition of a hardlink, it doesn't.
>> Probably worth fixing regardless of what we end up doing with hooks,
>> eg additional "setmeta" argument to fsmCommit() whether it should just
>> create or set the additional metadata as well, and have
>> pre/post-commit hooks get that so plugins get notified of all file
>> creations but also can avoid redundant setting of labels etc.
>
>> FWIW, this part is now pushed to git master, ie for hardlink sets the metadata (permissions etc) is only set once.
>
> I think this part looks good and clear, but indeed doesn't help with the below part.
>
>> I'm going to poke around with this a bit to see what would make most
>> sense, now that I have sufficient selinux plugin code to test it with.
>> Like said, I'm starting to have second thoughts on the skipped files,
>> so I'll probably look at changing the existing hooks to the "commit model"
>> rather than add more: for actually created (and removed) files, the
>> hook semantics would be rather obvious. With skipped (and some delayed
>> and
>> whatnot) files it gets far more convoluted. If it turns out the
>> plugins
>> *really* need the skipped file info as well, we can always add (back)
>> more hooks later on :)
>
>> Attached is one "study" into this direction, ie hooks are only called for files that are actually acted upon. This is a total diff of multiple commits with some semi-unrelated changes, so its more useful to look at the resulting code more than the diff itself.
>
>> I'm not going to push this stuff until further discussion + thought, if at all: the more I look and think about this stuff, something about it all just doesn't feel quite right :)
>
> It doesn’t look anything bad to me, but you are right below that we
> are now more like trying to fit these hooks somewhere to keep symmetry
> without even being sure we need it.

Indeed.

On the positive side, that "study" made me realize some bugs and other 
murky stuff in the code, so it wasn't all for nothing :)

>> Perhaps the problem is the hooks are too generic for their own good now.
>> One possibility (that's perhaps more clear with the other cleanup work in the patch) is to have a "set additional file metadata" hook, as
>> *that* is what our current use-cases (SELinux and MSSF) want to do.
>> Which should actually be as simple as adding something like this after all the fsmChown(), fsmChmod() etc calls:
>
>>      if (!rc)
>> 	rc = rpmpluginsCallFsmFileMeta(fsm->plugins, fsm->path, ...)
>
>> And actually that brings it right next to where fsmSetSELabel() is currently getting called. I've a feeling a symmetric pre/post-hook pair doesn't actually make sense for this particular purpose, it only complicates things unnecessarily.
>
>> Thoughts?
>
> I have been thinking about it now and I think having a hook for
> setting file meta data is a good idea in any case (even if we decide to
> keep pre/post hooks for some other purpose). It shows much clearer the
> purpose of the hook and it can be placed nicely exactly where metadata
> is set (and together with your latest commit it will be setting things
> right for hardlinks and etc.).

Ok, I think that's settled then: one specific hook for setting the file 
metadata and metadata only. Want to do the honors? :) I can add it as 
well if you're busy with the other stuff.

Ultimately it should be called for erasures too (obviously before 
actually erasing), but to cover all the cases that might need some 
further changes to the fsm to make it sane. I guess we could start with 
just doing the post-install hook which is by far the more important and 
interesting part and see about the pre-removal later.

> Another thing is if we still need some kind of pre/post hooks for
> files separately... I was trying to think of use cases beyond just a
> logging plugin that you were referring before.

I do think we need some kind of pre/post hooks for files in any case, 
but where exactly is the big question :)

> One more concrete use
> case that I now need to look to is using plugin interface for having a
> package virus scanner. The idea would be that plugin would scan the
> selected content from the package (native executables, maybe some
> scripts) and if any malicious pattern is detected, then do smth about it
> (preferably don't install the content at all to avoid it to be started
> even unintentially). The difficulty here is that plugin can't scan the
> code by itself (especially on mobile device) since it doesn’t have a
> knowledge to do so, so it would need to pass the content of a file in
> chunks to the actual scanning engine on the platform and get result:
> malware detected or not. Ideally if malware is detected, as a last layer
> of defence it would be very good not to call fsmcommit on that file and
> abort the installation with error to avoid file to be placed in real
> filesystem, but I guess it would be even better if the scan can happen
> even earlier that we don't need to abort the package installation in a
> such nasty way. If this can be done earlier, then I guess there is no
> need to pre/post hooks, but if not, they might be very much needed
> together with the update hook that we have already dismissed (it was
> used only for checksum calculation).

Right, that's a real-world use-case (unlike my "perhaps some logging 
might want to do some foobar with them" mumbling :) Scanning early is 
not really possible as the rpm API allows (by design) populating and 
starting the transaction with headers only, so that payload can be 
downloaded during the transaction. So at least for the foreseeable 
future it'd be limited to aborting a malware package from within fsm.

I see basically two options: either feeding the file bit by bit to a 
plugin as we read it, or using a pre-commit hook where the whole thing 
is unpacked onto disk but before moving to final position. The latter 
option seems far easier in many ways, both for the plugin and the 
rpm-side. OTOH there *could* be uses for hooks that get fed the files 
chunk-by-chunk, such as to allow custom checksums and the like. 
Checksums can of course be calculated from the final file in pre-commit 
too, but then you need to re-read the entire thing.

Another concrete use-case could be a plugin to put %config files into a 
version control of some kind. While this too would mostly be interested 
in actually created/erased files, it might actually want to know about 
%ghosts and such to be able to snapshot changes made by admin that 
might've occurred outside of the package. Guess this needs further 
thought, or better yet, actually trying to do it, but this might be a 
use-case for the current hooks as they are now, getting called for all 
files of a package whether actually touched or not.

	- Panu -



More information about the Rpm-maint mailing list