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 -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
