I use Felix 3.2.2 and Framework Security 1.4.2. 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
