Hi François,

Thanks, I hadn't seen that thread yet!
Indeed, the security layer is supposed to be able to handle my case.
The problem however is that I don't know how to do it let alone do it the right way.

Your code:

           final ConditionalPermissionAdmin cpa =

(ConditionalPermissionAdmin) context.getService(context.getServiceReference(ConditionalPermissionAdmin.class.getName()));

final ConditionalPermissionUpdate condPermUpdate = cpa.newConditionalPermissionUpdate(); final List<ConditionalPermissionInfo> permlist = condPermUpdate.getConditionalPermissionInfos();

            permlist.add(cpa.newConditionalPermissionInfo(null,
                        new ConditionInfo[]{

new ConditionInfo(BundleLocationCondition.class.getName(),

                                        new String[]{

context.getBundle(0).getLocation()

                                        }
                                )
                        },
                        new PermissionInfo[]{

new PermissionInfo(AllPermission.class.getName(),"", "")

                        },
                        "allow"));


Definitely points me in the right direction.
Would it be possible to create a custom bundle which listens to other bundles' events and apply a specific permission scheme based on the for example bundlename/location or other properties? If so how can I enforce such a scheme on another bundle?

Regards,

Sander

On 07/09/2010 02:07 PM, Goichon Francois wrote:
Hi Sander,


For the practical part, there is a start in this thread: http://www.mail-archive.com/[email protected]/msg07766.html

As it is said, static permissions cannot handle the dynamic code that are bundles. OSGi introduced a security layer to perform those dynamic checks. As for static permissions, you can grant specific permissions (classical ones + some OSGi-specific permissions) to specific bundles (by code location or by bundle signer, as for static perms). You can also deny some permissions, which isn't possible with classical Java perms.

In your case, you just have to grant permissions regarding their code location.

Hope that helps,

François

Sander de Groot <[email protected]> a écrit :

Hi,

After some research about security in OSGi I've found that it is fairly difficult to find examples of how permissions are set.
The following resources proofed to be usefull:
 - http://www.mail-archive.com/[email protected]/msg05090.html
 - http://www.osgi.org/download/r4v41/r4.core.pdf
- http://felix.apache.org/site/presentations.data/Building%20Secure%20OSGi%20Applications%20Workshop.pdf

Each of the links above contain a lot of theory but nothing practical really. My goal is fairly simple: I have got multiple bundles of a specific category (webapplications) each of these webapplications have their own 'home' directory. I want Felix to limit their file system access only to this home directory and if necessary a few other specifically assigned directories.

My question: how can I achieve this permission scheme?
Related questions:
* Is specifying permissions limited to specific boundaries? (like: bundlename, should the bundle specify its own permissions, etc.)
 * How can I discriminate different 'categories'/'types' of bundles
 * What about signing the bundles? Is this necessary, how to and why?

Before I was used to create my own SecurityManager which would limit the application programmatic. I don't mind using files or some other way but I'd like to be in full control.

Is this possible and so yes can you point me (or provide me) some examples?

Regards,

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]






---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to