[Rpm-maint] Plugin ponderings

Reshetova, Elena elena.reshetova at intel.com
Mon Nov 26 17:26:00 UTC 2012


I am attaching next version of the scriptlet-related patch. Next I will go
back to current hooks and make a small patch to make sure they are called as
we agreed. 
Will do this tomorrow. Also some comments below: 

> There's eg RPMRC_NOTTRUSTED that could be (ab)used for certain types of
security-related failures, but what if we have several plugins on a hook,
one returning RPMRC_OK, another one RPMRC_FAILED and the third one
RPMRC_NOTTRUSTED - which >one should the CallFooHook() function return? 
>One of the failures sure but...

The security theory is very easy for this case: the most restrictive
case/result is applied/returned. So, in this case I would return that we
failed on policy and indicate it with " RPMRC_NOTTRUSTED ". In this way rpm
can always enforce the strictest rule, for example if it wants to abort
installation after receiving RPMRC_NOTTRUSTED. 

> One possibility could be a bitfield type return code, where each plugin
can raise relevant bits of fairly generic categories. There's no telling
which plugin raised what bits, but at least it'd be possible to reflect more
than one kind of failure per hook then. >But again, mostly just something to
keep in mind / think about for now.

This would be cool, especially if we get LSM stacking accepted upstream! Now
there are active discussions on security mailing list on Casey's patches and
I can imagine that in the some distant future we can have a number of
simultaneous LSM working with rpm and a number of plugins that can use it.
And for each plugin we can log what happens and make rpm to be more aware.
But you are right: this is just future so far...

> We could just make the hook return "void", but perhaps its better to let
the hooks return errors codes and let rpm filter out (and perhaps log a
>warning) what it cant handle: its possible that some things it can't handle
now can be handled at some point in future.

Agree, I think it is good to give plugins possibility to complain, even if
the complains aren't heard at the moment. I just meant that maybe no reason
to invent new return codes just yet. 

> Note that rpm always creates files (but not directories) with a temporary
extension, and they're only rename()'d to final location (which might
replace existing files on upgrades) after everything was successfully
unpacked to the temporary locations. Rpm >doesn't currently do a proper job
of cleaning up the cruft in case of failure, but there is a chance to undo
at least some of the things before the fsm "commits" 
>the files to final destination.

Oh, this is actually very good, but I am not sure this is full solution. I
guess I need to study fsm machine more deeply. It is the hardest one for me
to understand so far :( 
Let's imagine we install a package and while putting its files to temp.
location security labelling fails on one of them (maybe even not the first
file and this is the bad thing). Plugin returns failure on that file in file
closed hook (which in this case would need to be moved before FSM commit).
What would be the proper behaviour? IMO we need to revert the whole package
installation unfortunately. Because if file is left on filesystem but not
properly labelled, then it might not be usable, and this might also lead to
app/service/daemon/whateverinstalledfrom package not usable too.  Do we want
such package on the filesystem then? But then the problem how do we remove
the files that has already been commited or if this file happens to be a

>At least in SELinux, rename() doesn't affect the security labeling so it'd
be possible to set the final contexts on the temporary files and only if
that succeeds for all files, commit the result. Currently the labelling is
done on the final destination so there's not >much chance of undoing in case
of failure.

Hm, isn't rename just a sub-case of mv? I think  in this case, xattrs might
not be preserved (for example for cp if you don't use --preserve=xattrs,
then you might lose your xattrs, including security labels (applies for both
SELinux and any LSM using the xattrs)). I would need to setup a small test
to remember this. But there should be a way for sure to move the files from
temporal location to final one while preserving all attributes, given that
rpm has needed privileges (which it does). I wonder if rpm could first
unpack all files and dirs to some temp location and then do one FSM commit
(if everything went fine) to commit them all one by one. This would solve
the problem of how to remove already installed files. 

> Yup... although some of this could be perhaps dealt with by rearranging
the way file permissions etc are laid down: currently they're all done on
the final destination, but if the labels, capabilities, modes etc were
staged in it would allow dealing with, well, >not all but at least more
failure cases. Would likely require quite some changes to fsm, but that's
not exactly a bad thing (we've been slowly rewriting the damn thing anyway

Yes, exactly my though above :) 

Best Regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Improving-scriptlet-related-rpm-plugin-hooks.patch
Type: application/octet-stream
Size: 9018 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20121126/ade924db/attachment-0001.obj>
-------------- 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/20121126/ade924db/attachment-0001.p7s>

More information about the Rpm-maint mailing list