[Rpm-maint] FSM hooks for rpm plugin

Reshetova, Elena elena.reshetova at intel.com
Wed Mar 6 10:39:22 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.

But if we keep pre-post hooks as they are and have this hook in addition, then maybe we can provide to a plugin a way to filter hardlinks also in pre-hook? This can serve as notification of hardlinks existence, and the pre-fsmcommit hook can be the actual hook for the acted files? Or is it too complicated?

Best Regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7220 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20130306/67fcb6a9/attachment.p7s>

More information about the Rpm-maint mailing list