Merci ! I'll search for the example and be back if I have more questions. From: [email protected] [mailto:[email protected]] On Behalf Of Pascal Rapicault Sent: 20 октомври 2011 г. 17:08 ч. To: P2 developer discussions Subject: Re: [p2-dev] Dynamic pluggability of touchpoints to the provisionig process ?
- "p2 enabled" means that there is a p2 folder with a valid p2 profile in the install. Let's refine a bit what happens: - Upon planning, p2 will create two plans. One for the installer see IProvisioningPlan#getInstaller, one for the installee - After that, the engine will have to first execute the plan returned by the getInstaller(), and then execute the real plan. For example this logic is encapsulated in PlanExecutionHelper. Therefore, if your code does not execute the installer plan, then you will be good wrt security. However if the site provider really needed something installed in the installer, then the execution of the installee plan will fail since some engine actions will be missing. You can find an example of this searching on the p2 ml or the wiki for metaRequirement. I had attached a p2 repo that demonstrated the functionality. On 2011-10-20, at 3:04 AM, Yousouf, Shenol wrote: Hello Pascal, Thank you for your reply and the advice ! I need some more details about this feature to understand the impact. Is there any documentation or examples that you could point me to ? "only if the installer is p2 enabled". Uhm, how should I interpret that ? :) Simply calling the p2 APIs (planner, engine, etc.) makes such a scenario possible ? Or to rephrase my question in a different way - can it happen if the p2 director is used (the logic in our tool is very close to it) ? To elaborate a little bit further - if such a functionality is buried deep inside the p2 code (i.e. cannot be controlled by the p2 client that calls the APIs), then we need to understand what can trigger modification of the installer on the fly - e.g. options, passed to the tool, specific attributes in the p2 repository, etc. Thanks and regards, Shenol Yousouf SAP Labs Bulgaria From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Pascal Rapicault Sent: 19 октомври 2011 г. 23:13 ч. To: P2 developer discussions Subject: Re: [p2-dev] Dynamic pluggability of touchpoints to the provisionig process ? It is not just your imagination, but the reality. p2 is capable of installing on the fly something in your installer, but only if the installer is p2 enabled. This installation is controlled by p2 as well. I understand the security concern, however I'll just throw this at you :) If you are concerned that the provider of the site is malicious enough to mess around with the installer, how can you trust any provider with what they add to your provisioned instance? Options that come to mind to protect yourself are: - Prevent things to be installed in the installer by having the installer be not p2 enabled. That has the drawback to prevent the installer to update itself if needs be. - Validate the signature of all bundles that get installed and restrict to only a few, and / or you go down the path of certification accompanied with signature (e.g. I provide you a bundle that will be installed in the intaller, you review the code and then you sign it with your own certs). On 2011-10-19, at 12:53 PM, Yousouf, Shenol wrote: Hello guys, In my scenario, I have a p2 installation tool (p2 director of the sort) which provisions another system. Assume that I have a repository with my own custom touchpoint and bundles, published with actions, recognized by it. Is it possible to plug dynamically the touchpoint to the provisioning process and execute the custom actions for the bundles, that go to the remote system, with one installation ? To clarify a little bit more: Our use cases rely heavily on p2 provisioning and we would like to clear the possible security holes. If such scenario is possible for, say, specially constructed update sites, this could lead to some unexpected results. Imagine that you install a feature, which turns out to contain a touchpoint + some bundles with actions, intended for it. If the new touchpoint can plug into the provisioning process at an early stage, it will execute the actions for the other bundles, which, on turn, can execute malicious code or do other nasty things. I have some vague memories that p2 supports some kind of "self-provisioning of the provisioning process" itself, which motivated me to direct this question to the mailing list, but it could be just my imagination. :) Thanks and regards, Shenol Yousouf SAP Labs Bulgaria _______________________________________________ p2-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/p2-dev _______________________________________________ p2-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
