[Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1
elena.reshetova at intel.com
Mon Nov 12 08:50:43 UTC 2012
>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
>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?
>- 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.
>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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7220 bytes
Desc: not available
More information about the Rpm-maint