I don't think it was necessarily a deliberate choice. But thinking about this a little bit, it likely is necessary in order to simplify the overall framework concepts and avoid having to keep in sync the security policy with the rest of the system. Services are event driven. In order to make this work seamlessly the framework would have to synthesize service events to be fired to service listeners that are effected by a change in the permission policy. This would not be a trivial task during performance sensitive area of the framework.
Also keep in mind that the issue with keeping the security policy "in sync" with the runtime is not limited to services. There is also the Package and Bundle permissions that effect the resolution in the module layer. Removing PackagePermissions does not immediately cause a bundle to be unresolved when it is wired to a package which it no longer has permissions for. The bundle needs to be re-resolved (refreshed) in order to be resolved correctly according to the current security policy. Tom From: <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 12/03/2013 08:53 AM Subject: Re: [osgi-dev] Declarative Services and Conditional permission Admin Sent by: [email protected] OK, thanks a lot for your quick answer. I guess I'll have to develop a start / stop functionality into my permission manager bundle then. Do you know if this point is a deliberate choice from the specification or just an unfortunate coincidence ? I'm working with Device Services (from Device Access) and use permissions to restrict access to devices to specific applications ; restarting an application to take into account a new device is feasible yet not really convenient. regards, Pierre De : [email protected] [[email protected]] de la part de Thomas Watson [[email protected]] Envoyé : mardi 3 décembre 2013 15:37 À : OSGi Developer Mail List Objet : Re: [osgi-dev] Declarative Services and Conditional permission Admin There is no permissions listener to be notified when permissions change. A DS runtime is not going to notice that a service is no longer visible when permissions change. Similarly a ServiceTracker is also not going to be notified (with the adding or removed methods) that a service is now visible or not to the BundleContext used by the ServiceTracker. This means that optional non-static service dependencies will not be dynamically injected when security changes. Also, there will be issues when taking away service permissions. A component Y that got injected with service X but then later service permission for X got revoked for the bundle with the component Y will not result in unbinding the service X from component Y. If this is a concern then I think you would have to detect which bundles are using the service X and restart them to make sure they use the new permission policy. Tom Inactive hide details for ---12/03/2013 08:13:01 AM---Hi all, I'm working with Declarative Service and I've just started to add---12/03/2013 08:13:01 AM---Hi all, I'm working with Declarative Service and I've just started to add security to our developmen From: <[email protected]> To: "[email protected]" <[email protected]>, Date: 12/03/2013 08:13 AM Subject: [osgi-dev] Declarative Services and Conditional permission Admin Sent by: [email protected] Hi all, I'm working with Declarative Service and I've just started to add security to our development using Conditional Permission Admin. There is a case where I'm not sure what is the expected behavior : I have a component which declares an optional and dynamic reference to a service, for which it's bundle does not have the necessary permissions : the component is activated but the service is not injected in the component (as specified in the security section of Declarative Services specifications). Now, what should happen if the permission are dynamically changed and the bundle can access the service : should the service be injected immediately (as it has the dynamic policy) ? I do not find anything in the specification about this question. This raises another question : is it possible for a bundle (SCR or not) to be notified when permissions have been changed ? Configuration Admin defines a ConfigurationListener to be notified of configuration changes, but I don't find anything similar for permissions. Any ideas about these issues ? regards, Pierre Rust _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
<<inline: graycol.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
