[Rpm-maint] FSM hooks for rpm plugin

Reshetova, Elena elena.reshetova at intel.com
Wed Mar 6 10:34:09 UTC 2013


>> 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.

Both works, but I think I can do it today: I don't have that much currently on my day plate. 

>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.

Ok, always easier to do it step by step.

> 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.

Yeah, in my second email I also started to lean towards the second option. So, it looks like your pre/post commit hooks study might be useful even more. You mentioned before that smth about it didn't feel right, do you have smth in mind or? 
If we now see a proper use case: like pre-commit can be used for content checking or even checksum calculation (I would still probably prefer to calculate it when it is read from archive: feels a bit safer that way, while I understand logically that if file is in tmp location and properly protected, nothing should happen to it anyway).

>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.

This almost drives us to have this set of hooks: 

1) pre/post where they are now
2) metadata hook (both install and remove)
3) pre fsm commit hook for checking on a file content ()

Indeed needs more thinking ....

Best Regards,
Elena.

-------------- 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/e6fd160b/attachment-0001.p7s>


More information about the Rpm-maint mailing list