Code X has Permission PP and can create a new PP (SecurityManager in
your example)
Calls Code Y which does not have permission PP and cannot create a new
PP (your bean in this case)
Which might call code Z which does have permission PP (your bean opening
up a new database connection)
Now, code X has the permission in it's context and can create a new PP
directly. Code Z inherits the permission context of Y and cannot create
a PP directly. It can do so, if it runs doPrivileged() in which case it
can do anything it was granted permission to do.
Code Y can scream and shout, but can never (even with the help of
doPrivileged() ) create a new PP.
arkin
Laird Nelson wrote:
>
> I've been beating my head against the doPrivileged() method for a while
> now and cannot understand it, due, obviously, to some blockage in my
> brain.
>
> If my EJB code is loaded, let's say, by something utterly hypothetical,
> like, oh, say, the Weblogic 5.1 classloader :-), and if that classloader
> has a policy file that designates that my EJB code is not, let's say,
> equally hypothetically, allowed to create a SecurityManager (not install
> one, mind you, but just create one), then am I correct in saying that no
> amount of tinkering with doPrivileged() will allow me to actually create
> said SecurityManager?
>
> The way I see it the only way to allow this operation to complete would
> be for the code that is *making* the doPrivileged() call to have the
> permission it needs. In which case it would be pretty stupid to use
> doPrivileged() anyhow, since if you already have the permission you
> don't need it any more.
>
> Thus spaketh O'Reilly on the subject:
>
> "[Because of the way doPrivileged() works] a protection domain can grant
> privileges to code that has called it, but it cannot grant privileges to
> code that it calls."
>
> If I read this right, this means that, for example, code loaded as part
> of the Weblogic classpath protection domain could grant *its* privileges
> to any potential callers of it (there aren't likely to be any), but
> cannot extend its permissions to classes that *it* calls.
>
> Or, rephrased, there is no way short of changing a policy file to allow
> my EJB code to create a security manager, whether through doPrivileged()
> or other means. Correct?
>
> (See, only *slightly* off topic. :-))
>
> Cheers,
> Laird
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
