Hi, Laird. Let's say there are two classloaders: the one that Weblogic uses for its implementation classes (e.g. ImplClassLoader), and the one that it uses to load your bean (e.g. BeanClassLoader). If the class that wants to do the privileged operation (say MyHelperClass) is loaded by the BeanClassLoader--for example, if it is in your bean's jar--then doPrivileged won't do anything. But let's say you put MyHelperClass on Weblogic's classpath, and it gets loaded by ImplClassLoader. Now the situation is more interesting. If you simply call MyHelperClass from your bean, this won't do any good. Normally, the security manager checks all the way up the stack to see if there is any unprivileged code before it allows a privileged operation. It finds your bean class immediately before MyHelperClass. Your bean class has been loaded by BeanClassLoader, which doesn't have the necessary privileges, and so the security manager won't allow the operation. BUT if MyHelperClass calls "doPrivileged," it is telling the security manager that it KNOWS it may be called from code without the requisite privileges, and it is ok to proceed even with unprivileged code on the stack. Remember, this only works if MyHelperClass has been loaded by a class loader with the correct privileges. Basically, the concept is that MyHelperClass is promising that it won't allow itself to be abused. This promise isn't worth much from untrusted code, right? If you want to do something from your bean that is normally disallowed by your server's security, you need to create a helper class, load it with a different class loader (e.g. by putting it on the classpath), and call it from your bean. There is no other way, as far as I know. Hope this helps. -Dan On 11 Apr 00, at 14:00, 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". > ------- End of forwarded message ------- =========================================================================== 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".
