>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 beginning. Best Regards, Elena.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
