Hi,
Yes. Container *can* stop EJBs from creating Threads. Whenever
a new Thread is created it checks to see if it has permissions to
modify the thread group.
But there is a problem if you rely on the default SecurityManager.
The default SecurityManager will only check the RuntimePermission
"modifyThreadGroup", if the thread group is "rootGroup". In other
words, the default SecurityManager is not being very strict about
checking for this permission.
Since we wish to make the checks more stricter, the Container
should install its own SecurityManager that should override
the checkAccess(ThreadGroup g) method in the SecurityManager.
Something like this.
public class ContainerSecurityManager extends java.lang.SecurityManager {
// A more strict implementation.
public void checkAccess(ThreadGroup g)
checkPermission(new
java.lang.RuntimePermission("modifyThreadGroup"));
}
}
Or, alternatively you could create a new Permission to represent
the Thread creation & perform a check in the checkAccess method.
Now for the question, how does one do the same in a JDK 1.1?
The solution to that is to install a SecurityManager like this
one: (Lets assume that the interface that a container implements
is com.abc.Container)
public class ContainerSecurityManager extends java.lang.SecurityManager {
public void checkAccess(ThreadGroup g) {
Class[] clss = getClassContext();
for(int i=1; i < clss.length; ++i)
checkIfWithinContainer(clss[i]);
}
}
private void checkIfWithinContainer(Class clazz)
Class[] parents = clazz.getDeclaredClasses();
for(int i=0; i < parents.length; ++i)
if(parents[i] == com.abc.Container.class)
throw new SecurityException("Access Denied ..");
}
}
-Harish
Enterprise Server Group.
Javasoftware Division
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> Sent: Friday, August 13, 1999 10:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Fwd: EJB and threads]
>
>
> Hey
>
> Vlada Matena wrote:
> > PS: Note that there is no security permission JDK to disallow
> an enterprise bean to
> > start a new thread. Therefore, we currently do not require that
> an EJB container be capable
> > of enforcing the rule that an enterprise bean must not start a
> new thread. We are looking
> > into a solution that would allow the container to enforce this rule.
>
> From java.lang.Thread.java (on constructor call, g is threadgroup):
> "
> /* checkAccess regardless of whether or not threadgroup is
> explicitly passed in. */
> g.checkAccess();
> "
>
> And in java.lang.ThreadGroup.java:
> "
> public final void checkAccess() {
> SecurityManager security = System.getSecurityManager();
> if (security != null) {
> security.checkAccess(this);
> }
> }
> "
>
> And finally in SecurityManager:
> "
> public void checkAccess(ThreadGroup g) {
> if (g == null) {
> throw new NullPointerException("thread group can't be null");
> }
> if (g == rootGroup) {
> if (threadGroupPermission == null)
> threadGroupPermission =
> new RuntimePermission("modifyThreadGroup");
> checkPermission(threadGroupPermission);
> } else {
> // just return
> }
> }
> "
>
> So not letting the bean have RuntimePermission("modifyThreadGroup")
> seems to do the trick. What have I missed?
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> Homepage: http://www-und.ida.liu.se/~ricob684
>
> ==================================================================
> =========
> 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".
>
===========================================================================
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".
