On Fri, Feb 15, 2013 at 5:47 PM, Łukasz Dywicki <luk...@dywicki.pl> wrote:
> I use Felix 3.2.2 and Framework Security 1.4.2. > That is very old - can you try with Felix 4.0.3 and security 2.0.1? regards, Karl > Wiadomość napisana przez Karl Pauls <karlpa...@gmail.com> w dniu 15 lut > 2013, o godz. 17:45: > > > > > On Fri, Feb 15, 2013 at 4:59 PM, Łukasz Dywicki <luk...@dywicki.pl> wrote: > >> After few hours more spent on CPM I may confirm - I don't blow JVM and >> framework. That's small success. :-) I've put results of my work to github ( >> https://github.com/splatch/osgi-cpm) my repiles inline. >> >> The most confusing part for me is why conditional permissions must be >>> cleared every time? >>> >> >> What does "cleared every time" mean exactly and what does conditional >> permissions imply? >> >> In activator of CPM administration module where I perform update I clear >> permission table. I belive it's not a preffered solution since it may >> remove other administration modules entries. Now it works, however with >> more than one administration module it will cause problems. Wouldn't be >> easier if CPM service would return only table of permissions previously put >> by bundle? >> >> >> >>> Why I need to also push java.security.AllPermission at the end >>> >> >> At what end and where to? >> >> If I will not put ALLOW java.security.AllPermission at the end of CPM >> update I will start getting errors with lack of access in different parts >> of framework. Maybe my access restrictions were to broad? >> >> - even if I have this granted in startup policy and >>> OSGI-INF/permissions.perm? From my understanding CPM should not affect >>> permissions granted by PermissionAdmin. >>> >> >> I'm not sure I understand what you are saying here. There is some >> interplay between CPM and PA but why are you using PA in the first place >> (and what has that to do with OSGI-INF/permissions.perm)? >> >> Possibly it's my missunderstanding of CPM or wrong restrictions range. >> ALLOW { >> [Condition] >> (java.io.FilePermission "file.txt" "read") >> } >> DENY { >> (java.io.FilePermission "file.txt" "read") >> } >> >> Without ALLOW AllPermission simply crashes framework and other services >> which tries to read disk. I learned that access rules must have exactly >> same statements except condition statements. Also pushing condition without >> BundleLocation/Signer condition is wrong idea. >> >> >> >>> My custom condition is executed, however I can not obtain subject. Also >>> it's not executed during execution of PrivilegedAction from security-test >>> module. >>> >> >> Hard to say without looking at what you are doing in more detail. Doing a >> doPriv in the security-test might be the wrong thing to do. You need a >> doPriv in the condition, not necessarily in the test... >> >> Now you may check code and observe what's going on. I even put multiple >> statements into test module: >> * execute action without authentication >> * execute with Subject.doAs >> * execute with Subject.doAsPrivileged >> >> In all cases my custom permission is not executed to verify access. >> Subject.doAsPrivileged gets simply full access and ignores CPM rules. Maybe >> it's guilty of AccessController, I don't know. In fact doAs[Privileged] >> have Subject instance and uses SubjectDomainCombiner. Looks that these >> checks are non-framework aware. >> > > Are you using equinox? If so, that will not work as you are using the > AccessController directly. Try using the SecurityManager instead to check > access. In felix it should work with both. > regards, > > Karl > > >> Cheers, >> Lukasz Dywicki >> -- >> Apache Karaf Commiter >> http://dywicki.pl >> >> >>> 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 >>> >>> >>> >>> 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 >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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
