On Fri, Jul 16, 2010 at 9:04 AM, Sander de Groot <[email protected]> wrote:
> On 07/15/2010 10:45 PM, Karl Pauls wrote:
>>
>> On Wed, Jul 14, 2010 at 4:49 PM, Sander de Groot<[email protected]> wrote:
>>
>>>
>>> Despite of all my attempts I unfortunately still haven't solved my case.
>>> Its true that everything is denied by default, however is it also true
>>> that
>>> all relevant permissions have to be positive to allow the action?
>>>
>>
>> The order o the rules is important. If a rule is found which allows
>> the required permission and has all its conditions satisfied the
>> action is permitted (i.e., no other rules are evaluated) otherwise the
>> next rule is evaluated until there either is no more rule or we hit a
>> deny rule that matches the permission (a matching and satisfied deny
>> rule allways terminates).
>>
>
> Right, so it does not evaluate all rules but terminates at the first rule
> allowing or denying the specified action?
> (Or denies if there aren't any rules, right?)
yup.
> If this is so then we need to work top-to-bottom as in most specific to most
> generic? E.g. deny/allow /var/var1/var2 and then allow/deny /var/var1/* ?
>>>
>>> For instance: I can't say deny everything but allow 'this'.
>>>
>>
>> Right, but you can say allow this and deny everything (again, order is
>> significant).
>>
>>
>>>
>>> And if there are other conflicting permissions, OSGi will deny the
>>> action, right?
>>>
>>
>> Not shure what "other conflicting permissions" are in this case...
>>
>
> As you described there can't be conflicting permissions because OSGi stops
> evaluating as soon as it finds the first match.
> To clarify: conflicting permissions could be two permission rules which
> override each other (in other words: the first rule allows and the second
> denies)
>>
>>
>>>
>>> My case is as follows:
>>> I've got a large amount of bundles of which I want an unspecified amount
>>> of
>>> bundles from a specific directory to be limited in permissions.
>>>
>>> I'm currently using a policy file which represents PermissionInfo's and
>>> ConditionInfo's. I'm just not sure on how to use variables in the
>>> filters.
>>> It doesn't work but it does show want I'm aiming for.
>>>
>>> DENY {
>>> # Only apply the rule if the bundle comes from this dir
>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>> "${felix.root}/webapps/-" ]
>>> ( java.io.FilePermission "!(/specific/path/${bundle.propertyX}/-)"
>>> "*")
>>> } "Deny all access to files"
>>> ALLOW {
>>> # If the bundle does NOT come form this specific dir
>>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>>> "${felix.root}/webapps/-" "!" ]
>>> ( java.security.AllPermission "*" "*")
>>> } "Allow everything else"
>>>
>>> Rules:
>>> - Every bundle except bundles from directory '${felix.root}/webapps/-'
>>> have
>>> allpermissions
>>> - Bundles from '${felix.root}/webapps/-' only have access to dir:
>>> '/specific/path/${bundle.propertyX}/-' nothing more
>>>
>>> Is it possible to do this without creating new Condition classes? If not,
>>> what's the best way to get the requested result?
>>>
>>
>> This will not work:
>>
>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>> "${felix.root}/webapps/-" ]
>>
>> try:
>>
>> [ org.osgi.service.condpermadmin.BundleLocationCondition
>> "${felix.root}/webapps/*" ]
>>
>
> Why? I thought the only difference between - an * was the recursive aspect?
Did you try it? The BundleLocationCondition is not a FilePermission so
why are you assuming it follows the same rules? Where in the spec does
it say it supports the same wildcards as filepermission?
>> (obviously, you can't use ${felix.root} out of the box...
>>
>
> But I can use ${} as property-access system?
Out of the box? No. You could extend the policy bundle to give you
some kind of property substitution but you have to do that yourself.
> Does it parse this kind of
> variables? And if so, what variables are available?
No.
>> What is the problem you have? Its hard for me to see what could be
>> going wrong because of your "properties" i don't understand but are
>> you sure this is correct:
>>
>
> My goal:
> All bundles loaded from a specific directory need to be constrained to one
> specific directory each. (So bundleX from that directory gets directory
> /var/bundles/bundleX/ and bundleY gets directory /var/bundles/bundleY/ where
> everything else is denied)
You probably want to write your own condition and or permission as i
don't see an easy way doing this with the provided
condition/permissions.
regards,
Karl
>> java.io.FilePermission "!(/specific/path/${bundle.propertyX}/-)" "*")
>>
>> Why is there a "!" in there and what is ${bundle.propertyX)?
>>
>
> The '!' is for inversion, just like in Java itself. What I'm trying to
> achieve with this rule: deny everything unless the directory is your 'home'
> directory.
>
> The property is for distinguishing the bundles. Since there will be a lot of
> bundles in that protected directory I can't make rules for every specific
> bundle.
>
> The propertyX is a specific property attached to the bundle in question. All
> permission requests will be coming from a specific bundle, I was hoping this
> bundle is known at evaluation time. The goal of this property thus is
> assigning a specific directory for a specific bundle (no shared directory).
> The property could be any property, like the bundle name, cannocial name or
> maybe a specific property defined runtime or in the manifest.
>>
>> regards,
>>
>> Karl
>>
>>>
>>> On 07/12/2010 11:57 AM, François GOICHON wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> For the practical part:
>>>>
>>>>>
>>>>> Do you have an examples of how to grant permissions? ( for example
>>>>> granting allpermission to the system bundle? )
>>>>>
>>>>
>>>> This is exactly what the sample code in the other thread does.
>>>>
>>>>>
>>>>> Or even better, do you have an example of how to limit a bundles' file
>>>>> permissions purely to one directory?
>>>>>
>>>>
>>>> permlist.add(cpa.newConditionalPermissionInfo(null,
>>>> new ConditionInfo[]{ new
>>>> ConditionInfo(BundleLocationCondition.class.getName(), new String[]{
>>>> "file:"
>>>> + webappdir + "*" }) },
>>>> new PermissionInfo[]{ new
>>>> PermissionInfo(FilePermission.class.getName(), "myDirectory/-",
>>>> "read,write") },
>>>> "allow"));
>>>>
>>>> In your example code you use the deny action but, by default, everything
>>>> is denied and you can add permissions. "Deny" can be used to restrict
>>>> existing permissions. For example, denying a specific permission in
>>>> allpermission, or allowing to read any file, but those from a specific
>>>> directory.
>>>>
>>>> Regards,
>>>>
>>>> François
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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]
>
>
--
Karl Pauls
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
