On 7/16/10 11:57, Sander de Groot wrote:
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?
Yes but there wasn't any difference because of the missing variable
parser.
I've now tried the following snippet:
# The first rule which denies or allows is applied
ALLOW {
[ org.osgi.service.condpermadmin.BundleLocationCondition
"webapps/dist/*" ]
( java.io.FilePermission "/home/sander/Downloads/-" "read,write")
} "Allow access to a specific dir"
DENY {
[ org.osgi.service.condpermadmin.BundleLocationCondition
"webapps/dist/*" ]
( java.io.FilePermission "/-" "read,write")
} "Deny access to all other directories"
ALLOW {
( java.security.AllPermission "*" "*")
} "Allow everything else"
but all bundles from webapps/dist/* are still able to write wherever
they want...
Are you sure that's the correct location of your bundles? Perhaps you
should do an "lb -l" in the shell to verify that's your location string.
-> richard
The snippet above follows the rules you told are applied (first rule
counts): it should restrict bundles from webapp/dist only to
/home/sander/Downloads/
(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.
Okay.
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.
That's a shame. Not that I mind writing my own conditions but I don't
seem how I could write my own file permission since this is integrated
in Java itself or am I mistaken? I'm quite new to the security model
of Java and don't know how it exactly works nor how OSGi integrates
with the security model of Java. I've seen some presentations and read
a few things about it and I intend to go through the source so I'll
know what I'm talking about.
I think I've got only two options left:
1. Hard-code everything
2. For each added bundle create a config item
Do you have any (other) suggestion?
Regards,
Sander
regards,
Karl
---------------------------------------------------------------------
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]
