Hi Lukasz, I must admit, I'm not sure I understand what you did so you might have to explain it again. However,
* OSGi-INF/permissions.perm has nothing to do with granting permissions. It is only there to allow a bundle to limit the permissions it gets. * There is no standard policy file in OSGi (it only looks like that would be the case in the spec) - If you want something like that you have to write it yourself (or use the one I wrote for the security chapter in OSGi in Action: http://code.google.com/p/osgi-in-action/source/browse/#svn%2Ftrunk%2Fchapter14%2Fcombined-example%2Forg.foo.policy ). * Assuming by "custom permission" you are talking about custom _condition_ yes, it is somewhat tricky to trigger security checks inside a security check. However, it should be possible - are you sure the code base of your custom condition has enough permissions and you do whatever you do inside doPriv blocks? You can find an example of a custom condition here: http://code.google.com/p/osgi-in-action/source/browse/trunk/chapter14/combined-example/org.foo.condition.ask/src/org/foo/condition/ask/AskUserCondition.java ). Finally, I admit that it is possible that the combination of custom condition that uses JAAS to determine the current subject isn't possible but that would be a bug in felix so we would need to take the discussion there maybe. Otherwise, this is what i would try: Write a custom condition that does determine the current subject via JAAS from inside a doPriv block when it is asked whether it is satisfied and returns true if the subject equals the subject name given in the parameters of the condition. Create a policy file that has an ALLOW for this condition with the name of the subject and the permissions that you want to give to it. Put the condition on the classpath and start felix with the security provider and the policy bundle installed and see if it works. regards, Karl On Thu, Feb 14, 2013 at 8:38 PM, Łukasz Dywicki <luk...@dywicki.pl> wrote: > Dear all, > I was looking for something similar to grant for given principal > authorized by JAAS login module in OSGi world. I thought that > ConditionalPermissionaAdmin (CPM) will be solution of my problems, however > it failed to cover the scenario. > > I have very simple code to test security layer using standard Java > mechanism. My JAAS configuration: > Unix { > com.sun.security.auth.module.UnixLoginModule required; > }; > > Policy configuration: > grant Principal com.sun.security.auth.UnixPrincipal "workshop" { > permission java.io.FilePermission "file.txt", "read"; > }; > > This example allows to open "file.txt" when JVM is launch by user > "workshop". There are many examples, where this may be used and unix > principal is used just because it doesn't have any external dependencies. > With this kind of configuration I may grant access to given permissions > using given principal (GroupPrincipal "admin" to administer bundle states > for example). > > I launched my example under Felix 4.x with Felix Security 2.0.1. However, > what I have observed - seems that OSGI-INF/permissions.perm must have > following syntax: > (permissionClass "resource", "action") > > I had following OSGI-INF/permissions.perm file: > ALLOW { > [com.example.PrincipalPermission "admin"] > (java.io.FIlePermission "file.txt", "read") > } "read file by admin group" > > I have login module which is capable to verify user credentials and > perform authentication. My code is executed with > Subject.doAsPrivileged(subject, action, null). I haven't tried that with > Equinox yet. > > Another thing is usage of AccessControllContext inside custom permissions > - it causes stack overflow (I use > Subject.getSubject(AccessController.getContext())). I don't know how to > avoid that since my custom permission must obtain Subject instance to > obtain given permissions but it doesn't have access to subject instance. I > don't want hack with ThreadLocals since it will break compability with JAAS > layer used by many libraries. > > Did you ever got something like this running with CPM? If so, please share > tips with me. > > Cheers, > Lukasz > -- > Apache Karaf Commiter > http://dywicki.pl > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
