P3
FULL PRODUCT VERSION :
Java(TM) SE Runtime Environment (build 1.6.0-rc-b104)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b104, mixed mode, sharing)
coco@coco-laptop:~/Desktop/Transient-(NoBackup)/Mustang/jdk1.6.0/jre/bin$
ADDITIONAL OS VERSION INFORMATION :
Linux coco-laptop 2.6.17-10-generic #2 SMP Fri Oct 13 18:45:35 UTC 2006 i686 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
It seems that the "preferences" policy is specious.
Preferences defines a permission, "preferences". It is possible to implement a backing store in a sandboxed environment, for instance, using JNLP PersistenceService. But the current architecture prohibits deployment of such an implementation.
To implement a custom provider, one can define a factory implementation and any custom Preferences objects. However, to get a node, user code invokes a static method in Preferences. This method's implementation checks the security privilege and fails, even though a provider may be present that works within the sandbox.
I do not currently understand how this could be remedied: it seems at first that it's not possible since the permission is not part of the sandbox's set, so no solution would work - barring of course simply removing the policy and the check. Yet as I've said, it's possible to implement at least user-level preferences with cookies/muffins, and certainly a complete implementation using the server to store the prefs.
The limitation seems flawed.
Since the implementation artifacts are all channeled through the xxSpi methods it seems like any security check should be happening at this point and not earlier. In any case, it seems to me that the sensitive operation is the file system access and not "preferences" behavior; which is why I say the policy seems flawed. And it is possible to use cookies in the sandbox, but it's not possible to implement Preferences that call into that due to this policy's existence.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Invoke the static userRoot() method in Preferences while running in a sandboxed environment.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The policy to be governed by the installed service provider.
ACTUAL -
The implementation in Preferences never even consults the factory, but checks the policy: and just fails immediately.
REPRODUCIBILITY :
This bug can be reproduced always.
Java(TM) SE Runtime Environment (build 1.6.0-rc-b104)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b104, mixed mode, sharing)
coco@coco-laptop:~/Desktop/Transient-(NoBackup)/Mustang/jdk1.6.0/jre/bin$
ADDITIONAL OS VERSION INFORMATION :
Linux coco-laptop 2.6.17-10-generic #2 SMP Fri Oct 13 18:45:35 UTC 2006 i686 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
It seems that the "preferences" policy is specious.
Preferences defines a permission, "preferences". It is possible to implement a backing store in a sandboxed environment, for instance, using JNLP PersistenceService. But the current architecture prohibits deployment of such an implementation.
To implement a custom provider, one can define a factory implementation and any custom Preferences objects. However, to get a node, user code invokes a static method in Preferences. This method's implementation checks the security privilege and fails, even though a provider may be present that works within the sandbox.
I do not currently understand how this could be remedied: it seems at first that it's not possible since the permission is not part of the sandbox's set, so no solution would work - barring of course simply removing the policy and the check. Yet as I've said, it's possible to implement at least user-level preferences with cookies/muffins, and certainly a complete implementation using the server to store the prefs.
The limitation seems flawed.
Since the implementation artifacts are all channeled through the xxSpi methods it seems like any security check should be happening at this point and not earlier. In any case, it seems to me that the sensitive operation is the file system access and not "preferences" behavior; which is why I say the policy seems flawed. And it is possible to use cookies in the sandbox, but it's not possible to implement Preferences that call into that due to this policy's existence.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Invoke the static userRoot() method in Preferences while running in a sandboxed environment.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The policy to be governed by the installed service provider.
ACTUAL -
The implementation in Preferences never even consults the factory, but checks the policy: and just fails immediately.
REPRODUCIBILITY :
This bug can be reproduced always.