[Rpm-maint] FSM hooks for rpm plugin

Reshetova, Elena elena.reshetova at intel.com
Wed Feb 27 07:18:15 UTC 2013

>Right, no surprises: there is an issue with hard links :)

Oh, this is smth I should have actually remembered, but forgot :( I saw the 
issue a while back on our system setup, but since from security labelling 
hard links aren't interesting (security context should be set on a file 
itself, not a hard link), I simply didn't call hooks for hard links. But I 
agree that it might be important to know that they will be created and I guess 
in this case we would need to know when and where it goes. Actually not from 
labelling point of view, but from general security, a tightly configured 
system might have restrictions on where files/dirs/links are created. For 
example, it might not allow creating hard links in certain paths (in order for 
system to stay well arranged or for example in order to avoid untrusted 
packages creating hard links in sensitive dirs). The thing here is that such a 
check should be probably performed before we start to run FSM and unpacking 
the archive (for the same reason as conflicts). So, then if we consider that 
labelling and policy enforcement aren't valid use cases here, we only have 
informational use case left: plugin wants to know the links and their location 
as for any other files. Should we then create separate hook/call same hook 
(with modified parameters) actually at the moment when links are created 
(later on)?

>Regardless of how exactly the hardlinks are handled, perhaps we should pass a 
>pointer to the entire stat struct instead of just st_mode to the hooks, 
>that'd at least allow plugins to know they're dealing with hardlinks (and 
>various other possibly useful >information).

I guess this is true, should be easy to change.

>A different issue (much easier and one that we already discussed iirc) is 
>that I think we must check the return code from
>rpmpluginsCallFsmFilePost() and allow it to fail, otherwise its not possible 
>to preserve the current behavior where eg failure to set SELinux context (or 
>other similar security thing) causes package installation to fail.

I am always very supportive for giving more power to the plugin :)  I think 
that it is possible to setup a system that failure to set a security context 
for files from the package might not result in security compromise, but then 
it might make package unusable and the effort required to do this is much 
bigger (we would need to play with security context of running rpm, which 
isn't that great). So, yes, I guess failing in this case is the easiest way.

>The good news is that other than the two above issues, the plugin API seems 
>to work quite nicely for SELinux.

These are really good news! I was expecting more problems actually in 

Best Regards,
-------------- 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/20130227/0de32c3c/attachment-0001.p7s>

More information about the Rpm-maint mailing list