[Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1

[Panu Matilainen]

On 11/08/2012 01:01 PM, Reshetova, Elena wrote:
>> Okay then, done and pushed. Now that I looked closer, I spotted (and
>> fixed) a couple of more "issues": a tiny memleak from early
>> rpmtsSetupTransactionPlugins() return and some further cosmetics (two
> soft-tabs instead of one hard-tab, trailing whitespace etc), but nothing
> dramatic.
>
> Thank you!  I will seriously try to improve my style. I am not using vim for
> code edits, but I think I should probably reconsider it or get some kind of
> editor that shows all symbols explicitly. Pain to read but I get it right at
> the end :)

If you dont otherwise use vim, might be easier to figure out how to 
configure your preferred editor to honor the rpm style - since its 
essentially just K&R I'd assume pretty much any coding-oriented editor 
can deal with that. Vi(m) is a fairly strange beast initially :)

>
>> Oh and one other thing I noticed just now that'll need further thought:
>> currently the script setup hook only runs for external scripts, but not the
> embedded Lua-scripts. Which are getting more and more common...
>> They'll obviously need to be handled quite differently as they run within
> the rpm process itself, ie fork() + exec() does not occur.
>
> Yes, I don't currently have a very good idea how this case should be
> handled. The idea of script hook is that it sets the needed security
> context, but we obviously can't do this for lua case unless we want to drop
> the whole rpm security context.
> As a temporal and draconic measure we can compile rpm without lua support to
> close this hole, but it is no-go in the future since it is getting more and
> more usage. I guess this is one of the things that I need to think more
> about.

In case of SELinux, AFAICS a process can change its own context back and 
forth, IF permitted by the policy. So at least in theory it should 
possible to switch to a different context while executing a scriptlet 
and then switch back to the original context.

Perhaps the script hook should just follow the common pre/post-hook 
pattern of the other hooks afterall: pre-hook would just replace the 
current setup hook, and post-hook would run after the script got 
executed. If we add an extra argument to notify the hooks whether it's 
an internal or external script (or a more generic "flags" argument to 
allow passing more such bits later), the plugin(s) should be able to 
figure out what to do about it.

	- Panu -