I'm going to raise this as an issue on Jira, however I want to be sure I
haven't overlooked something first, so I've cc'd this to a number of
you, I know many of you are busy, so won't be offended if you're unable
to weigh in, if there are other reasons for not responding to the list
please fee
"But what if we want to use a service with a smart proxy without granting
trust? So I can use it while running as my Subject, allowing me to use my
public credentials for authorisation to run as my Subject on the services
server (with another set of Principals assigned by the service server),
with
Hmm,
Very eloquently put, you describe typical corporate IT behaviour, I
can't refute that.
In most if not all cases Subject.doAs is executed only in the presence
of trusted code or code assumed trusted.
And yet, I'd like to have the ability to run as a Subject with less
trusted code, call
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 custom
> DomainCombi
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 gra
Peter Firmstone wrote:
3. In Jini security documentation I've seen on the web,
Subject.doAsPrivileged is called with a null AccessControlContext
executing the proxy, in doing so the proxy PD is no longer on the
stack, however it isn't clear when the proxy ProtectionDomain will
No, sorry, I was right the first time it definitely is a security problem, the
alternate method proposed still has too many pitfalls for the unwary,
developers are likely to make mistakes due to complexity, security needs to be
simpler. The current methods are brittle when used in a remote cont
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
