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".
