[Rpm-maint] FSM hooks for rpm plugin

Panu Matilainen pmatilai at laiskiainen.org
Wed Mar 6 08:08:19 UTC 2013


On 03/06/2013 09:42 AM, Reshetova, Elena wrote:
>> 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.).
>> 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.  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 i
nstallation 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).
>
> Actually while thinking more about it, I think the cleanest way is
> toprocess the file when it has been unpacked to tpm location, but hasn't
> been committed yet. The file is already on filesystem, but since it is
> in tpm location and without proper attributes, it is quite limited on
> what it can do. This would make a need of one more hook somewhere just
> before fsmCommit happens. I would put it just after this piece of code
> in fsm.c to make sure it is called only for real files and not dirs,
> symlinks and etc.:
> 1721                 if (rc == CPIOERR_ENOENT) {
> 1722                     rc = expandRegular(fsm, psm, archive, nodigest);
>
> I think this hook can be called smth like FsmFileCheck() or smth
> likethis and it can be used for content checking or any other checks on a
> file before it is transferred to a final location.
> Do you think it make sense?

I think the more generic option would be a pre-commit hook somewhat 
similar to what my "study" patch does, where it only gets called for 
files that are actually acted on but where the plugin just needs to 
filter out directories, links etc that its not interested in. Although 
there's still the question of what to do with hardlinks in these cases: 
the plugin should be at least notified about it somehow.

	- Panu -



More information about the Rpm-maint mailing list