[Rpm-maint] Script hooks patch

[Panu Matilainen]

On 11/23/2012 07:32 AM, Reshetova, Elena wrote:
> Hi,
>
>
>
> Please ignore the previous path: I should have just went to sleep yesterday

Heh, I know the feeling :)

>
> Somehow it got locked in my head that case when execv might fail is a
> special case (which of course it is, but not for this) and we need to call
> the hook there also to indicate this. Complete nonsense when you look at it
> with fresh head.
>
> The corrected patch attached!

I see a couple of further problems with this:

- runLuaScript() will leak memory and a file descriptor if 
rpmpluginsCallScriptPre() fails.
- For external scripts the hooks run on different sides of the fork(): 
pre-hook runs in the forked child, post-hook in the parent, so parent 
will be unaware of anything occurring in the pre-hook.

I'd prefer the hooks called from rpmScriptRun() already so there would 
be exactly one place where to deal with them, but whether that would 
actually work is a different question entirely...

External scripts have a lengthy setup sequence in the child between the 
fork() and exec(), including a call to rpmExpand() on 
%_install_script_path. Which should not, but technically could, have a 
shell-invocation in it, which would cause a fork() + exec() of its own 
which would cause (at least in case of SELinux) the exec context setup 
to go to wrong address. It should be possible to move the rpmExpand() 
into parent and just pass the path as an argument to doScriptExec() 
though but just goes to show how the kind of minefield this is.

Internal scripts present different problems: as it is now, there's not 
much difference between calling hooks from runLuaScript() and 
rpmScriptRun(), but if we assume they'll get forked in the future, any 
security context switch would have to happen after the fork. Which 
inevitably causes the same asymmetry with pre- and post-hooks as there 
is now with external scripts.

One way to address it would be having an "unpaired" post-fork (or 
pre-exec if you like) hook that explicitly runs in the child process, 
which basically is what we have now in the script setup hook. Which then 
begs the question: what exactly are the new script pre- and post-hooks 
supposed to be used for? Ok, I can imagine eg logging plugin wanting to 
do something in both of those, but...

	- Panu -