[Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1
pmatilai at laiskiainen.org
Thu Nov 15 13:58:25 UTC 2012
On 11/12/2012 10:50 AM, Reshetova, Elena wrote:
>> Scripts run with all the powers that rpm itself has, and there's not a
> whole lot that can be done about it: scriptlets expect to, and often need
> to, do all sorts of crazy things.
> True, but we would actually like to be able to limit things that scripts can
> do. It is ok for a script to create a new file or to call ldconfig, but in
> our setup it is not ok for script to start relabeling the xattrs on
> filesystem (you can do this with CAP_MAC_ADMIN for example) or rewriting
> important system files (you can do this with CAP_MAC_OVERRIDE and
Understood, and I see nothing wrong with wanting to limit the damage
rogue/runaway scriptlets can do. If you control the entire package set
and compatibility with arbitrary 3rd party "big vendor" packages (which
are the ones that traditionally do utterly crazy things) isn't an issue
then certainly some level of added control is possible.
>> The differences from regular exec()'ed scripts and Lua-ones are basically:
>> - As Lua scripts run in the rpm process space, some extra protection is
> needed, like saving + restoring current working directory, umask and
> preventing Lua scriptlet from exec()'ing or exit()'ing the process.
> Just out of interest, is there are reason for them actually to run in rpm
> process space as opposite to doing the same as for regular scripts?
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
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.
>> - There are no context switches for Lua scripts in SELinux world
>> currently: Lua scripts run with rpm_exec_t context, "regular" scripts run
> with rpm_script_t. But both are practically omnipotent contexts, because
> they have to be.
> Stephen, do you have any plans related to Lua-scripts?
> I guess the reason it wasn't touched so far is the same as for us: when
> script is run in the same context, very little can be done to make it with
> little priviledge and still be able to continue rpm operation.
See above, I suppose we could add a configuration/compile-time switch or
such to fork() the embedded script execution and then you wouldn't have
to worry about getting the privileges back.
>> Oh, I meant the common pre- and post-hook pattern seems like it would make
> sense for scripts too in any case, regardless of whether it helps solving
> the context issue. It *might* in the SELinux case, but a post-hook could
> have some other entirely different uses, and it'd make the whole thing a bit
> more >symmetric :)
> Sure, I can make the hooks to follow the same principle. Just I would need
> to understand how the post-hook would be used in order to figure out proper
> arguments and decide if we want it to be called if script fails or not.
> I guess I would rather call post-hook then even if script has failed, but
> juts indicate the failure. What do you think should be the argument of
> post-script hook? Return code from the script (to know if it failed or not)
> and maybe script path again then?
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 :)
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.
- Panu -
> Best Regards,
More information about the Rpm-maint