Re: [Rpm-maint] FSM hooks for rpm plugin
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
Re: [Rpm-maint] [PATCH] Fixup find-requires linking for srcdir != builddir.
On 03/05/2013 10:31 PM, Mark Wielaard wrote:
When configuring with srcdir != builddir the find-requires link would fail:
ln: failed to create symbolic link './autodeps/find-requires'
Do the link in the same way as find-provides with an explicit ${srcdir}.
Applied, thanks. I typically build with src == builddir so this kind of
stuff tends to go entirely unnoticed.
- Panu -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Getting make check to work
On 03/05/2013 11:15 PM, Mark Wielaard wrote:
Hi,
I am probably doing something wrong with configuring, but I cannot get
make check to work with the attached patch. And even with that half of
the tests fail because for some reason there is a literal '${prefix}'
string used somewhat that cause the creation of an extra directory
tests/testing\$\{prefix\}/ next to the tests/testing one which contains
just var/lib/rpm/
I also tried with srcdir == builddir and with the latest release
4.10.3.1 instead of a git checkout and on fedora 18. But the issue
is always the same with lots of failures because something seems to
use '${prefix}' literally.
I am configuring with: --with-external-db \
CPPFLAGS=-I/usr/include/nspr4 -I/usr/include/nss3 -I/usr/include/db4
Does this ring any bell?
Indeed it does... there's an ages old flaw in the configure/make system
that causes this unless you pass an explicit --prefix or --localstatedir
to configure. Should really do something about it, just never gotten
around to it :-/
Meanwhile, the patch looks ok (make check still worksforme :) -
applied, thanks.
- Panu -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] FSM hooks for rpm plugin
Another issue I just realized is that with this patch, the metadata hook call
is not under the setmeta condition so it will get called always, ie in cases
like hardlinks when it specifically should *not* be called :)
I think the fsm-part should be something like this instead:
@@ -1569,6 +1569,11 @@ static int fsmCommit(FSM_t fsm, int ix, int setmeta)
}
if (setmeta) {
+ /* Run fsm metadata hook for all plugins */
+ if (!rc) {
+ rc = rpmpluginsCallFsmFileMetadata(fsm-plugins,
+ fsm-path, st, fsm-action);
+ }
/* Set file security context (if enabled) */
if (!rc !getuid()) {
rc = fsmSetSELabel(fsm-sehandle, fsm-path, fsm-sb.st_mode);
Ups, indeed, will fix!
smime.p7s
Description: S/MIME cryptographic signature
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] FSM hooks for rpm plugin
On 03/06/2013 12:34 PM, Reshetova, Elena wrote: 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? That something was mostly about trying to fit the symmetric hooks through asymmetric use-hole, but that's not all: I still have this nagging feeling we're missing some obvious way of doing this all in a simpler way. Or something to that direction... exposure to the fsm tends to mess up any clear thinking :) 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). Yup, if you get it directly from the source then nothing can be tampering with it, and certainly for at least checksum calculation is going to be more efficient if you can do it on the fly (but then rpm can do multiple checksums already, what's missing is exporting that functionality in a sane way). OTOH if something can tamper with the file that we're creating then it can do nasty stuff anyway, so its perhaps a bit academic. 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 Naah, we just need more hooks! :P Seriously though, I've started thinking of that very same set of hooks so we're probably not too far off-target here. But now I find myself wondering whether 2) is actually necessary afterall: if we have pre- (and perhaps post too) commit hook, and can pass in some additional information as file action flag bits... we could have something like FA_SETMETA bit for the entries where its appropriate (ie non-hardlinks I guess), and if there's a post-commit hook as well, the plugins can decide whether to set permissions before or after rpm. Yes, needs more thinking :) - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
