[Rpm-maint] FSM hooks for rpm plugin

Panu Matilainen pmatilai at laiskiainen.org
Wed Mar 6 13:59:35 UTC 2013

On 03/06/2013 01:14 PM, Reshetova, Elena wrote:
> Hi,
> I am attaching the fast write-up of a metadata hook. While it is dead simple,
> there are actually two things that made me think:

Heh, seems nothing is as simple as it initially seems in this area.

> - Should it be called before or after setting the standard metadata, such as
> owner, caps and etc.?
>   I chose to do it before because I don't think that there is a need for a
> plugin to mess up with standard metadata that can be transferred by rpm
> itself, but
> this is arguable. One might think that in some cases security plugin wants to
> enforce a stricter policy for example on file capabilities
>   (example: package might not be enough trusted to get CAP_MAC_ADMIN),
> but then it becomes that plugin and rpm are setting two different things....
> So, might be better to reject installation of such package then instead
> installing it without the right cap.

Good question, coming up with arguments for both cases is not 
particularly hard. OTOH if plugins are allowed to mess with the standard 
metadata, rpm -V is going to show failures for changed 
permissions/ownership etc. Of course we could also do both, but... :)

I think calling the hook before rpm sets the metadata is the simpler and 
saner approach at least for starters.

> - For the hook arguments, I think it is worth to give whole stat struct to the
> plugin as we discussed and I decided to keep action, too. Especially when we
> add this hook on removal, it would be very useful.


> I don't think any other arguments are needed (at least not to SELinux and
> msm), but maybe I missed smth.

What's missing is that another call to the hook is needed in fsmMkdirs() 
for the unowned directories, and there we should perhaps pass in the 
"unowned" aspect somehow. Having a separate argument for that seems like 
an overkill though... maybe we could pass that piece of info in the 
action argument instead. One possibility could be adding a new action, 
eg FA_CREATEUNOWNED that could be used for unowned directories (and 
files, but there aren't any currently). Or we could define the action as 
a partial bitfield: leave the existing actions alone but reserve the 
"upper" byte for special bits, such as "unknown". I had some other 
use-case for turning it into (partial) bitfield but can't remember what 
it was right now.

	- Panu -

More information about the Rpm-maint mailing list