Gregg Wonderly wrote:
On Jul 7, 2012, at 8:02 AM, Peter Firmstone wrote:
These doAs methods in this case cannot elevate Permission, they can reduce
Permission to that which the Subject has in common with other code on the
stack, but it cannot be used by code to gain privilege if it uses a
On Jul 22, 2012, at 5:04 AM, Peter Firmstone wrote:
Since Gregg hasn't utilised traditional jvm style Permissions for Principals,
there is no possibility of elevating privileges when calling Subject.doAs, so
granting doAs to untrusted code doesn't present any security risk in
Gregg's use
Thanks Gregg,
The services you deploy are often unique, but relevant and it's apparent
you've been able to explore and delve deeply into complex problems. I'm
grateful that both you and Dan are finding some time to discuss this
issue, because to be quite honest, I'm not happy that I fully
Consider a Subject ProtectionDomain that is added to the stack, instead of
Subject Principals being injected into every domain on the stack:
Subjects don't have code, they lack the ability to use one permission to gain
another, so if a ProtectionDomain representing only a Subject and its
Thanks Dan Gregg,
I've been working on the overhead problem, here's a summary (will commit
the latest after tests finish):
1. Removed calls to CodeSource.implies (this causes a DNS lookup)
2. Replaced URL with URI in Policy providers (URL requires DNS lookup
and File system access)
What follows is relatively hard core security, but it's relevant to anyone
wishing to deploy on untrusted networks. I know some people don't like
discussing security issues for fear of turning off would be developers but
security isn't mandatory, however considering that River/Jini is already
