[Rpm-maint] [PATCH] plugins/systemd_inhibit.c: Define DBUS_TYPE_UNIX_FD if undefined.
Older dbus versions (at least 1.2.24) don't define it by default. --- plugins/systemd_inhibit.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/plugins/systemd_inhibit.c b/plugins/systemd_inhibit.c index badcc9e..1dd66e6 100644 --- a/plugins/systemd_inhibit.c +++ b/plugins/systemd_inhibit.c @@ -3,6 +3,10 @@ #include rpm/rpmts.h #include plugin.h +#ifndef DBUS_TYPE_UNIX_FD +#define DBUS_TYPE_UNIX_FD ((int) 'h') +#endif + rpmPluginHook PLUGIN_HOOKS = ( PLUGINHOOK_INIT | PLUGINHOOK_CLEANUP | -- 1.7.1 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] plugins/systemd_inhibit.c: Define DBUS_TYPE_UNIX_FD if undefined.
On 03/05/2013 04:24 PM, Mark Wielaard wrote: Older dbus versions (at least 1.2.24) don't define it by default. --- plugins/systemd_inhibit.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/plugins/systemd_inhibit.c b/plugins/systemd_inhibit.c index badcc9e..1dd66e6 100644 --- a/plugins/systemd_inhibit.c +++ b/plugins/systemd_inhibit.c @@ -3,6 +3,10 @@ #include rpm/rpmts.h #include plugin.h +#ifndef DBUS_TYPE_UNIX_FD +#define DBUS_TYPE_UNIX_FD ((int) 'h') +#endif + rpmPluginHook PLUGIN_HOOKS = ( PLUGINHOOK_INIT | PLUGINHOOK_CLEANUP | Hum... dbus 1.2.24 would be RHEL-6'ish, right? In which case the whole plugin makes no sense at all because it actually needs to have a fairly recent systemd running on the system to do anything at all. Dunno, I can certainly apply that but then again it might make more sense to not even try compiling it with dbus that old, as anything with that old dbus version is highly unlikely to be running systemd in the first place (which however is something that cannot be tested for during build) - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Rpm Database musings
On Mon, Mar 04, 2013 at 12:22:31PM +0100, Michael Schroeder wrote:
For 2000 packages we have about... ugh, that's actually hard
to tell as the avg and the median differ that much. Let's
use the average: 2000 * 130 = 26 files.
I would hash them using just a 32-bit number for each hash entry,
the number would be a combination of the hash value and a header
number. Thus:
26 - 2^19 = 524288 hash entries (49% fill size)
hash(basename) = ...
--13 bits-- -- 19 bits--
Thus we store 13 bits of the hash value together with the header
number (we may need a header number - header db idx array to keep
the header number small, but that just needs 2000 * 4 bytes).
I would not store the real string on disk, in most cases we
need to retrieve the real header anyway, our db function
can simply fetch the header and make sure that it's not a false
positive. Chances for that are pretty slim anyway, as we have the
extra 13 bits in the entry.
Hmm, turns out that it works only well if we have a really good
hash function. The simple hashing I do in libsolv can't be used
as too many files map to the same hash value. I tried the
popular MurMurHash, it seems to do a good job. Disadvantages
of the scheme are the excess header fetches and there's also no
fast way to get all the keys from the hash (needed for rpm's new
IndexIterator).
If we don't want to access excess headers, we need to put the
strings into the hash. Here's the data for my machine:
filelist entries: 238032
- hash entries: 524288
- hash memory used: 4 * 524288 = 2 Mbyte
unique basenames: 207686
basename stringspace needed: 3355117 bytes = 3.2 MByte
This assumes that we can somehow address the string from the
32bit hash value. I have 2099 package installed, this needs
12 bits. That leaves us with 20 bits for the string offset, which
is not enough (2^20 = 1048576). We might put the strings at
a somewhat aligned offsets, thus we would need max 3 excess bytes
for aligning, making the needed space 3355117 + 3 * 207686 =
3.8 MBytes, which is smalled than 1048576 * 4.
It's probably easier to just use 2 * 32bit for the hashing, i.e.
the needed size is 2 * 2 MByte hash + 3.2 MByte strings.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] plugins/systemd_inhibit.c: Define DBUS_TYPE_UNIX_FD if undefined.
On Tue, Mar 05, 2013 at 07:15:30PM +0200, Panu Matilainen wrote: Hum... dbus 1.2.24 would be RHEL-6'ish, right? In which case the whole plugin makes no sense at all because it actually needs to have a fairly recent systemd running on the system to do anything at all. Dunno, I can certainly apply that but then again it might make more sense to not even try compiling it with dbus that old, as anything with that old dbus version is highly unlikely to be running systemd in the first place (which however is something that cannot be tested for during build) Yes, RHEL 6.4 to be precise. An alternative would be checking for dbus 1.3+ which has DBUS_TYPE_UNIX_FD. See attached. Cheers, Mark From 5220c09a6a41e1b7cd9ec721409a7a069f9cc2b6 Mon Sep 17 00:00:00 2001 From: Mark Wielaard m...@redhat.com Date: Tue, 5 Mar 2013 20:35:19 +0100 Subject: [PATCH] Require dbus = 1.3 for DBUS_TYPE_UNIX_FD usage. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 7fd7c5e..ba68d84 100644 --- a/configure.ac +++ b/configure.ac @@ -747,7 +747,7 @@ AM_CONDITIONAL(ENABLE_PLUGINS,[test $enable_plugins = yes]) with_dbus=no AS_IF([test $enable_plugins != no],[ PKG_CHECK_MODULES([DBUS], -[dbus-1 = 1.0], +[dbus-1 = 1.3], [AC_DEFINE(DBUS, 1, [Build with dbus support?]) with_dbus=yes], [with_dbus=no]) AC_SUBST(DBUS_CFLAGS) -- 1.8.1.4 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] plugins/systemd_inhibit.c: Define DBUS_TYPE_UNIX_FD if undefined.
On 03/05/2013 09:38 PM, Mark Wielaard wrote: On Tue, Mar 05, 2013 at 07:15:30PM +0200, Panu Matilainen wrote: Hum... dbus 1.2.24 would be RHEL-6'ish, right? In which case the whole plugin makes no sense at all because it actually needs to have a fairly recent systemd running on the system to do anything at all. Dunno, I can certainly apply that but then again it might make more sense to not even try compiling it with dbus that old, as anything with that old dbus version is highly unlikely to be running systemd in the first place (which however is something that cannot be tested for during build) Yes, RHEL 6.4 to be precise. An alternative would be checking for dbus 1.3+ which has DBUS_TYPE_UNIX_FD. See attached. Right. Given the target of that plugin requiring dbus = 1.3 seems fair (the 1.0 version requirement was really just drawn out of a hat) Applied, thanks for the patch! - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Getting make check to work
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?
Thanks,
Mark
From 8ee4a07b970a834547dff1d95343a9ff86cb4597 Mon Sep 17 00:00:00 2001
From: Mark Wielaard m...@redhat.com
Date: Tue, 5 Mar 2013 21:52:36 +0100
Subject: [PATCH] tests: Make sure testing/usr/bin exists and to copy data from
srcdir.
When srcdir != builddir the data has to be copied over from the srcdir.
When any of the required progs comes from /usr/bin then there also needs
to be a usr/bin under testing. Just use the same symlink as for testing/bin.
---
tests/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 61c18af..6a9f0e1 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -101,10 +101,11 @@ testing$(bindir)/rpmbuild: ../rpmbuild
ln -s ./$(bindir) testing/bin
(cd ${top_builddir} \
$(MAKE) DESTDIR=`pwd`/${subdir}/testing install)
- cp -r data/ testing/
+ cp -r ${srcdir}/data/ testing/
mkdir testing/{dev,etc,magic,tmp}
for node in stdin stderr stdout null; do ln -s /dev/$${node}
testing/dev/$${node}; done
for cf in hosts resolv.conf passwd shadow group gshadow mtab fstab; do
[ -f /etc/$${cf} ] ln -s /etc/$${cf} testing/etc/$${cf}; done
+ ln -s ../$(bindir) testing/usr/bin
for prog in gzip cat patch tar sh ln chmod rm mkdir uname grep sed find
file mktemp cut sort diff; do p=`which $${prog}`; ln -s $${p} testing/$${p};
done
for d in /proc /sys /selinux /etc/selinux; do if [ -d $${d} ]; then ln
-s $${d} testing/$${d}; fi; done
(cd testing/magic file -C)
--
1.8.1.4
___
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
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
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).
Actually while thinking more about it, I think the cleanest way is to process
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 like this 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?
Best Regards,
Elena.
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/04/2013 10:56 AM, Reshetova, Elena wrote: Looking at this, I just realized that rpm is currently doing chmod(), chown() and all for each hardlink it creates, which just doesn't make sense because ... by the very definition of a hardlink, it doesn't. Probably worth fixing regardless of what we end up doing with hooks, eg additional setmeta argument to fsmCommit() whether it should just create or set the additional metadata as well, and have pre/post-commit hooks get that so plugins get notified of all file creations but also can avoid redundant setting of labels etc. FWIW, this part is now pushed to git master, ie for hardlink sets the metadata (permissions etc) is only set once. I think this part looks good and clear, but indeed doesn't help with the below part. I'm going to poke around with this a bit to see what would make most sense, now that I have sufficient selinux plugin code to test it with. Like said, I'm starting to have second thoughts on the skipped files, so I'll probably look at changing the existing hooks to the commit model rather than add more: for actually created (and removed) files, the hook semantics would be rather obvious. With skipped (and some delayed and whatnot) files it gets far more convoluted. If it turns out the plugins *really* need the skipped file info as well, we can always add (back) more hooks later on :) Attached is one study into this direction, ie hooks are only called for files that are actually acted upon. This is a total diff of multiple commits with some semi-unrelated changes, so its more useful to look at the resulting code more than the diff itself. I'm not going to push this stuff until further discussion + thought, if at all: the more I look and think about this stuff, something about it all just doesn't feel quite right :) It doesn’t look anything bad to me, but you are right below that we are now more like trying to fit these hooks somewhere to keep symmetry without even being sure we need it. Indeed. On the positive side, that study made me realize some bugs and other murky stuff in the code, so it wasn't all for nothing :) 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. 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. 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
