On 11/20/2012 01:45 PM, Reshetova, Elena wrote:
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.
Plugins being able to deny scriptlet execution on per-package (or
scriptlet) basis seems entirely reasonable to me, considering the goals
discussed here. Regardless of whether its embedded lua or a "normal"
scriptlet.
The better one would be only to setup the security context but this would
require the fork().
I'm starting to think we'll want the ability to fork lua execution
anyway. I've just been pondering over the details: simply always forking
Lua scriptlets would make a whole lot of sense and eliminate the need to
try and protect rpm from the things lua scripts can do. But like said,
that would break any lua scriptlets depending on the in-process
execution. Which might actually be just a good thing in a way. Another
possibility is making the forking configurable, but its fairly ugly and
wouldn't allow us to get rid of the fragile "try save and restore any
damage lua might do to us" stuff.
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
hooks?
Smaller sets are always preferred as they're easier to review. If you
have the scriptlet stuff ready, just fire away :)
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
