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 -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
