> Hi Alex, > > Am Dienstag, den 26.02.2008, 17:57 +0100 schrieb Alexander Saar: > > I have only one question that is due to my limited knowledge of OSGI. > > Is there anything like a security concept that controls access to > > OSGI services? As far as I understand the proposed changes the service > > locator will then use the BundleContext from the bundle that provides > > the according script engine. Can such a service locator always access > > every registered OSGI service? If not how can I control the access? > > Probably the ServiceLocator will use the BundleContext of the > scripting/resolver bundle and not that of any specific scripting engine. > But this is a minor detail in this discussion. > > Point is, that is theoretically possible to limit the accessibility to > services for certain bundles (and even users IIRC). This is specified in > the security part of the core OSGi specification. It is also possible to > limit certain method calls (e.g. Bundle.stop()) as specified for the > respective method.
Right, the OSGi spec considers security and builds it's own permission management infrastructure on top of Java security. Basically, in addition to the normal Java permission checks all other OSGi related operations are doing their own permission checks. > So if we provide a ServiceLocator based on a certain bundle, we of > course inherit the security context of said bundle. No for code provided > by bundles (e.g. OSGi services or bundle-based scripts) this may be > fixed by using the appropriate BundleContext to access services. Depending on what exactly you have in mind it might be some work involved but it is definitely possible to get this done. > But for JCR based scripts, this is different and would probably be based > around > user-based security. It should be possible to merge user-based security with the code based one of OSGi. In general, this is not part of the spec but it is doable. > Currently, we do not have this level of security enforced. And I have to > admit, that this is not currently the part of the OSGi specification I > understand the best ... Maybe Karl Pauls may be able to jump in, if I > got something completely wrong. One issue to keep in mind is that for OSGi security to work we will have to run with security enabled :-). This will definitely eat some performance. Another one is that we would need to look into all of the sling core to give it the right permissions or at least configure a catch all permission for sling core things. Finally, Felix doesn't have security right now but I'm almost ready to commit a first version (probably by the end of the week). > Hope this helps. > > Regards > Felix btw. Marcel and I will give a OSGi security tutorial at eclipsecon next month: http://www.eclipsecon.org/2008/?page=sub/&id=300 regards, Karl -- Karl Pauls [EMAIL PROTECTED]
