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

[Panu Matilainen]

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 -