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.
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
