[Rpm-maint] Plugin findings

Reshetova, Elena elena.reshetova at intel.com
Thu Mar 28 10:52:48 UTC 2013


Hi,

> There's really nothing like field-testing when it comes to finding
issues... Now that I simply have to run with the selinux plugin enabled
(otherwise I'd have a very broken system real fast), hacking on new plugins
revealed a some fairly nasty issues in the plugin system (and caused a fair
bit of head-scratching >early in the morning :) that's gone merrily
unnoticed so far:

I have actually only tested and use the hooks with one plugin (msm), so I
guess some issues could have slipped though, indeed :(

> When there are more than one plugins present, an unsupported hook (or
errors like not finding the hook) in one plugin will cause all the remaining
plugins to be skipped on that hook. This is because
>RPMPLUGINS_SET_HOOK_FUNC() does 'return <rc>' on several conditions, which
doesn't go very well with for-loops...

Oh, yes, I see this... One way would be to change it to a normal function
that would return the state, but won't break the loop. The question is how
to differentiate between "hook returned RPMRC_FAILED" and "hook isn't
supported", which are indeed very very different things. 

>Another related thing is that RPMPLUGINS_SET_HOOK_FUNC() is executed
several times per each file in the transaction, times number of plugins
loaded. It didn't matter for the collection plugins as they are so different
in nature, but now with several hooks per each file its just terribly
wasteful if nothing >else.

Hm.. How do you plan to avoid this? If you have let's say a security
(selinux or msm) plugin and a log plugin, or two different security plugins
(future LSM stacking), each plugin would need to get a hook called.

> So... I'm planning on doing some fairly major surgery on the whole thing.
Just checking whether you have some work-in-progress in this area, IIRC you
were planning to look into changing the plugin initialization (move it much
earlier etc) and I dont want to clash with that work if you've already
started it.

I have put aside the initialization work so far, since we were concentrating
on fsm hooks, so there is nothing to clash with for sure! 

> FWIW the kind of thing I have in mind is make plugins into "objects" 
>that hold their own data (like name, symbol handle etc) and hooks are
function pointers in the struct that are initialized when the plugin is
first loaded so we dont have to rediscover the hook functions on each and
every round, etc.

This sounds good, would make it easier indeed! 

Best Regards,
Elena.

-----Original Message-----
From: Panu Matilainen [mailto:pmatilai at laiskiainen.org] 
Sent: Thursday, March 28, 2013 12:32 PM
To: Reshetova, Elena
Cc: rpm-maint at lists.rpm.org
Subject: Plugin findings

Hi,

There's really nothing like field-testing when it comes to finding issues...
Now that I simply have to run with the selinux plugin enabled (otherwise I'd
have a very broken system real fast), hacking on new plugins revealed a some
fairly nasty issues in the plugin system (and caused a fair bit of
head-scratching early in the morning :) that's gone merrily unnoticed so
far:

When there are more than one plugins present, an unsupported hook (or errors
like not finding the hook) in one plugin will cause all the remaining
plugins to be skipped on that hook. This is because
RPMPLUGINS_SET_HOOK_FUNC() does 'return <rc>' on several conditions, which
doesn't go very well with for-loops...

Another related thing is that RPMPLUGINS_SET_HOOK_FUNC() is executed several
times per each file in the transaction, times number of plugins loaded. It
didn't matter for the collection plugins as they are so different in nature,
but now with several hooks per each file its just terribly wasteful if
nothing else.

So... I'm planning on doing some fairly major surgery on the whole thing.
Just checking whether you have some work-in-progress in this area, IIRC you
were planning to look into changing the plugin initialization (move it much
earlier etc) and I dont want to clash with that work if you've already
started it.

FWIW the kind of thing I have in mind is make plugins into "objects" 
that hold their own data (like name, symbol handle etc) and hooks are
function pointers in the struct that are initialized when the plugin is
first loaded so we dont have to rediscover the hook functions on each and
every round, etc.

	- Panu -
-------------- 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/20130328/fa4bfb29/attachment-0001.p7s>


More information about the Rpm-maint mailing list