[Rpm-maint] FSM hooks for rpm plugin
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
>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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7220 bytes
Desc: not available
More information about the Rpm-maint