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

Reshetova, Elena elena.reshetova at intel.com
Tue Nov 20 11:45:34 UTC 2012

>The most important use-case is to make it possible to run scripts when even
/bin/sh is not available. Such as %pretrans scripts on initial install -
there simply nothing to exec() in that environment. Or if the package
containing /bin/sh or one of its dependencies needs scripts, there's no
other choice than an >embedded script during initial install.
>Related to that, one can avoid problematic external dependencies in the
early "bootstrap" stages of initial install.
>It also allows some things that aren't really possible otherwise, such as
manipulating macros and "communicating" with other packages through the
global Lua environment (and in theory, accessing rpmdb but that's not
implemented), which would not be possible in an externally executed script.
>It would be possible to fork() for the execution of embedded scripts
without compromising the main use-case of early install, but it would break
some possible uses of the second group. Whether that's a good or bad
thing... is a different question. I dunno if anybody is actually using the
current possibilities >in that area.

Thank you for explaining! Now I start to understand this a bit better.
Providing better interfaces and possibilities for trusted packages to do
needed things is always good, I guess the only thing would be to have the
possibility for a plugin to implement restrictions if necessary.
I agree that it would be better to make some decision on per script/package
basis whenever this lua script is allowed to run and with what privileges
instead of simply saying "disable lua at compile time" . I think the
solution that plugin would return an error code n pre-script execution if it
thinks that lua scipts aren't allowed is actually an acceptable one for now.
The better one would be only to setup the security context but this would
require the fork().  

>Good question... symmetry is usually good, so I guess the post-hook 
>should be always called if pre-hook was called. Script path + return 
>code as arguments seems like a reasonably starting point at least. (I'm 
>not really even dreaming of getting every single detail 100% right the 
>first time :)

Ok, I will do it this way. I actually have these changes ready, but wanted
to finish with three main filesystem hooks at the same time. I am hoping to
do it this week. 

>And like said, I think the plugin hooks should get called with embedded 
>scripts too. It'll probably need another argument to let the plugins 
>know whether an internal or external script is about to be executed - 
>you could eg just deny execution of internal scripts from non-trusted 
>sources then, without disabling lua entirely.

Yes, I agree, this is a better alternative to a complete lua disabling. I
will do it this way. 
Do you want the script changes in separate path then without any filesystem

Best Regards,

-------------- 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/20121120/11c313a8/attachment.p7s>

More information about the Rpm-maint mailing list