Hi, After reading your responses I think we indeed need to break this patch into at least two or three parts. It would help us to concentrate on one set of the hooks at the time and integrate them separately in steps. You mentioned that pre/post tsm/psm hooks are pretty much fine, so we can start from them. I would propose to add to them a security plugin loading function and macros. Also, if there are no objections I would add here a ScriptSetup hook (it is rather simple one and outside of other hooks). This can be the first bunch that we can bring into shape to be acceptable for merge. Then after the above is hopefully merged I will start attacking the file-related hooks (I have already made a number of changes and will look into improving them further based on your comments). And at the end we can talk about how to integrate the rest. I will post the first bunch shortly if there are no objections. Further comments are inline: >Actually, the ability to sanely disable these things from cli and API is in practise a hard requirement. The reason is that rpm is used in a large variety of situations beyond the basic "system package management" >task: creation of chroot (build-)environments that are nothing like what the system might be running, install/live images, certain per-user tasks, workarounds for weird setups etc. Plus all the things we never even imagined - by now I hope to have learned (the hard way) that no matter how unlikely it >seems, the unforeseen oddball (yet legal) cases always exist :) >I do realize that needs on an embedded / handheld systems can be drastically different from a general purpose system. How to support "full lockdown" where needed but allow disabling for other uses is something to think about. Hm.. This isn't easy indeed. Can we make a security plugin a special case regarding to the cli? Meaning that if the rpm is compiled with "ENFORCE_SECURITY", then it isn't possible to disable the security plugin from cli and if loading/expanding of security plugin fails, then rpm stops. Providing cli or API option to disable additional security enforced by the plugin(s) even if security have been compiled in sounds scary for me.... >What I was thinking was more in the direction of "if plugin X returned failure, should we even call the other hooks" (such as falling back to something else if one of the involved filesystem doesn't support feature Y), but this is now something that neither the plugin or rpm has any way of actually knowing. >The point perhaps being, the exact semantics for the plugin hooks needs to be far more clearly defined sooner or later. I think even if plugin X returns failure on hook Z, we need to call the hook Z for all other plugins, because this will make sure that all plugins have the same set of hooks that got executed during the rpm transaction. Also, it would be up to each plugin to be prepared that rpm transaction can stop and fail outside of the plugin (inside rpm itself or inside of other plugins) and then be ready that only cleanup hook is called. So, for example, plugin might have pre tsm/psm hooks called and they go fine, but then some other plugin returns a failure on prepsm hook, so whole transaction goes to failure and plugin gets cleanup hook called even if from its point of view everything went fine. >FWIW, I've been considering exporting the fd digest API for quite some >time. That stuff probably needs a bit of polishing/sanitizing before >exporting, but I'm not at all opposed to doing it. Yes, I think this would be good and then it can be cleaner from plugin side to get digest calculated. >For now, go for the absolute minimum exposure of rpm "objects". The >problem here is different from the other internals (such as fsm in the >previous versions) exposure, the issue here is that it exposes a ad-hoc >set of things that rpm currently happens to internally use to handle >this stuff. Which is not entirely unlike Lucas Arts adventure games of >old: you have a rope, two bananas and a fish, and you need to somehow >use those to cross the ravine to get the umbrella from the other side >that you need to... :) >The fact that the hook breaks in rpm >= 4.10 despite arguments remaining >the same kinda underlines the issue. Rpm internals are going through >some pretty fundamental changes at the moment, and this is one of the >places that will hopefully become saner when its all done (my wishful >thinking is to have at least the basics around in rpm 4.11 already). >When that happens we can export more, but right now its better to keep >things to minimum you can get by with. Agree, I will take a stronger attempt to reduce the arguments to the actual needed once for all the file hooks. I guess the conflict one is the most heavy one at the moment, so I will try to address it properly next time I post the patch for file hooks. >The signature verification hook is another place where some weird >internal bits and pieces get passed around. That might be unavoidable, >dunno... but then (and I think I've said this before), signature >enforcing mechanism should really be in rpm core (and is sorely missed >currently). Plugins might further enhance / implement policy around >that, or something. Oh and I know this is hand-wavy and vague :-/ Yes, I think it would be good to think more on this. I understood how you would like to have it now and agree that this would be an ideal case. I will put this on my todo list to see how this can be done in a better way. >What I referred to above is specifically the file conflict resolution >thing (and our previous discussion about that). Eg looking at the MSM >plugin, AFAICT it can let conflicts pass at this point, yet deny it deep >down from inside when the transaction is already in progress. There >always will be cases where a failure cannot be detected before actually >trying to install (ie, in fsm), but that should be the absolute last >resort, not something you'd ever see in "normal" operation. Sure, I guess this problem is about the actual hook content, not necessary the hook itself. I guess the hook should be redone to not simply log the conflict case and decide on it later, but actually decide before starting a transaction. I am quite sure I can change it in the plugin itself. Best Regards, Elena.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
