On 10/10/2012 05:21 PM, Panu Matilainen wrote:
I think this was one of the prime reasons I had that look into the
"security manager" object thingie: to avoid having to pass the
transaction
set to places where it really does not belong to.
OTOH it would seem to me (most of) the places could simply be passed a
handle to the plugins instead of ts, as the ts is pretty much only
used for
ts->plugins.
True, I think this is that I will do: it still requires adding the
plugins
as parameter to functions, but avoids adding ts_internal and ts
itself. I
will change my patch.
Oh BTW, you can avoid most of the new arguments to the fsm internal
functions by simply storing the plugins handle in the fsm struct itself
(just like sehandle currently is)
I understand these concerns (I think :), and tightening rpm security I
certainly have nothing against. I'm just perhaps looking at this from
slightly different perspective:
Many of these issues actually exist on general purpose systems as well:
for example you wouldn't generally want a 3rd party package from
somewhere to be able to replace (whether through updating or obsoleting)
a "system" package or its files. Or have that 3rd party package prevent
an important update that happens to conflict with a file that the 3rd
party package has already "claimed". So the kind of package priorization
by its source / signature and related policies is a much more generic
need than specialized handheld/embedded systems, the allowability (and
need) of overriding is what differs more (BTW, how does the user of an
embedded IVI or handheld device specify an rpm conflict override to
begin with?)
That's why I'm a bit doubtful over some things I see here: plugins
should not (have to) be by design doing strange things behind rpms back
to achieve what are actually common needs.
Also BTW, to avoid getting stuck from me piling up new demands (I do
realize that's what's happening here)... I see no reason why this whole
thing would absolutely have to be merged all at once or not at all, we
could start merging the easier parts first and worry about the more
complex issues later, eg:
1) the tsm/psm pre/post hooks are pretty much no-brainers
2) the fsm hooks are mostly obvious but need just a bit of further
thought/work as already discussed and agreed
3) figure out what to do with the remaining two hooks where at least
parts of the functionality should IMO be in rpm core
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
