ScheduledThreadPoolExecutor and shutdown permission check.

[Gregg Wonderly-2]

I have a STPE that I use in an applet.  At applet shutdown, I'd like to shutdown
the executor, but alas it requests a Permission check for a RuntimePermission
that I don't have in an unsigned applet.  It seems kind of silly to demand this
permission when no other thread management permission exist in the JDK for
applets.  Am I missing something in consideration of this issue?

Gregg Wonderly
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Ben Manes]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Have you tried using a daemon thread factory?  I haven't done much work with applets, but I'd venture that this would allow it to shutdown cleanly.

----- Original Message ----
From: Gregg Wonderly <gregg@...>
To: concurrency-interest <concurrency-interest@...>
Sent: Tuesday, April 29, 2008 10:29:46 AM
Subject: [concurrency-interest] ScheduledThreadPoolExecutor and shutdown permission check.

I have a STPE that I use in an applet.  At applet shutdown, I'd like to shutdown
the executor, but alas it requests a Permission check for a RuntimePermission
that I don't have in an unsigned applet.  It seems kind of silly to demand this
permission when no other thread management permission exist in the JDK for
applets.  Am I missing something in consideration of this issue?

Gregg Wonderly
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

---

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Gregg Wonderly-2]

Ben Manes wrote:
> Have you tried using a daemon thread factory?  I haven't done much work
> with applets, but I'd venture that this would allow it to shutdown cleanly.

The exception comes out of the STPE when I call shutdown or shutdownNow.  It is
performing an permission check that is creating the problem.  A different thread
type wouldn't help in this case.

Gregg Wonderly

> ----- Original Message ----
> From: Gregg Wonderly <gregg@...>
> To: concurrency-interest <concurrency-interest@...>
> Sent: Tuesday, April 29, 2008 10:29:46 AM
> Subject: [concurrency-interest] ScheduledThreadPoolExecutor and shutdown
> permission check.
>
> I have a STPE that I use in an applet.  At applet shutdown, I'd like to
> shutdown
> the executor, but alas it requests a Permission check for a
> RuntimePermission
> that I don't have in an unsigned applet.  It seems kind of silly to
> demand this
> permission when no other thread management permission exist in the JDK for
> applets.  Am I missing something in consideration of this issue?
>
> Gregg Wonderly
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> <mailto:Concurrency-interest@...>
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> ------------------------------------------------------------------------
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
> it now.
> <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 
>  >

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Ben Manes]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Yes, but my point was that there may not be a need for an explicit shutdown and an implicit one when the applet was stopped would solve most use-cases.

----- Original Message ----
From: Gregg Wonderly <gregg@...>
To: Ben Manes <ben_manes@...>
Cc: gregg.wonderly@...; concurrency-interest <concurrency-interest@...>
Sent: Tuesday, April 29, 2008 2:23:45 PM
Subject: Re: [concurrency-interest] ScheduledThreadPoolExecutor and shutdown permission check.

Ben Manes wrote:
> Have you tried using a daemon thread factory?  I haven't done much work
> with applets, but I'd venture that this would allow it to shutdown cleanly.

The exception comes out of the STPE when I call shutdown or shutdownNow.  It is
performing an permission check that is creating the problem.  A different thread
type wouldn't help in this case.

Gregg Wonderly

> ----- Original Message ----
> From: Gregg Wonderly <gregg@...>
> To: concurrency-interest <concurrency-interest@...>
> Sent: Tuesday, April 29, 2008 10:29:46 AM
> Subject: [concurrency-interest] ScheduledThreadPoolExecutor and shutdown
> permission check.
>
> I have a STPE that I use in an applet.  At applet shutdown, I'd like to
> shutdown
> the executor, but alas it requests a Permission check for a
> RuntimePermission
> that I don't have in an unsigned applet.  It seems kind of silly to
> demand this
> permission when no other thread management permission exist in the JDK for
> applets.  Am I missing something in consideration of this issue?
>
> Gregg Wonderly
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> <mailto:Concurrency-interest@...>
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> ------------------------------------------------------------------------
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
> it now.
> <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>  >

---

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Jason Mehrens]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Gregg,
 
Following report is related to your issue. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6575582
 
Jason

> Date: Tue, 29 Apr 2008 12:29:46 -0500
> From: gregg@...
> To: concurrency-interest@...
> Subject: [concurrency-interest] ScheduledThreadPoolExecutor and shutdown permission check.
>
> I have a STPE that I use in an applet. At applet shutdown, I'd like to shutdown
> the executor, but alas it requests a Permission check for a RuntimePermission
> that I don't have in an unsigned applet. It seems kind of silly to demand this
> permission when no other thread management permission exist in the JDK for
> applets. Am I missing something in consideration of this issue?
>
> Gregg Wonderly
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

---

Back to work after baby– how do you know when you’re ready?
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Joe Bowbeer]

On Tue, Apr 29, 2008 at 10:29 AM, Gregg Wonderly wrote:
> I have a STPE that I use in an applet.  At applet shutdown, I'd like to shutdown
>  the executor, but alas it requests a Permission check for a RuntimePermission
>  that I don't have in an unsigned applet.  It seems kind of silly to demand this
>  permission when no other thread management permission exist in the JDK for
>  applets.  Am I missing something in consideration of this issue?
>

Interesting.  So the exception is from TPE.shutdown() when it calls
checkPermission?

    private static final RuntimePermission shutdownPerm =
        new RuntimePermission("modifyThread");

    SecurityManager security = System.getSecurityManager();
    if (security != null)
        security.checkPermission(shutdownPerm);

Before checking to see if the current thread can interrupt the workers
-- even if none of the workers will actually be interrupted...

    if (security != null) { // Check if caller can modify our threads
        for (Worker w : workers)
            security.checkAccess(w.thread);
    }

The rationale is here

     * [ ... ] we must cooperate
     * with the security manager (if present), which may implement
     * policies that make more sense for operations on Threads
     * than they do for ThreadPools. This requires 3 steps:
     *
     * 1. Making sure caller has permission to shut down threads
     * in general (see shutdownPerm).
     *
     * 2. If (1) passes, making sure the caller is allowed to
     * modify each of our threads. This might not be true even if
     * first check passed, if the SecurityManager treats some
     * threads specially. If this check passes, then we can try
     * to set runState.
     *
     * 3. If both (1) and (2) pass, dealing with inconsistent
     * security managers that allow checkAccess but then throw a
     * SecurityException when interrupt() is invoked.  In this
     * third case, because we have already set runState, we can
     * only try to back out from the shutdown as cleanly as
     * possible. Some workers may have been killed but we remain
     * in non-shutdown state (which may entail tryTerminate from
     * workerDone starting a new worker to maintain liveness.)

What should it do?

--Joe
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Gregg Wonderly-2]

Ben Manes wrote:
> Yes, but my point was that there may not be a need for an explicit
> shutdown and an implicit one when the applet was stopped would solve
> most use-cases.

The STPE is used in a class which has hundreds of instances created and
destroyed over the life of the applet.  If I use daemon threads won't they still
be parked when idle?

Gregg Wonderly

> ----- Original Message ----
> From: Gregg Wonderly <gregg@...>
> To: Ben Manes <ben_manes@...>
> Cc: gregg.wonderly@...; concurrency-interest
> <concurrency-interest@...>
> Sent: Tuesday, April 29, 2008 2:23:45 PM
> Subject: Re: [concurrency-interest] ScheduledThreadPoolExecutor and
> shutdown permission check.
>
> Ben Manes wrote:
>  > Have you tried using a daemon thread factory?  I haven't done much work
>  > with applets, but I'd venture that this would allow it to shutdown
> cleanly.
>
> The exception comes out of the STPE when I call shutdown or
> shutdownNow.  It is
> performing an permission check that is creating the problem.  A
> different thread
> type wouldn't help in this case.
>
> Gregg Wonderly
>
>
>  > ----- Original Message ----
>  > From: Gregg Wonderly <gregg@... <mailto:gregg@...>>
>  > To: concurrency-interest <concurrency-interest@...
> <mailto:concurrency-interest@...>>
>  > Sent: Tuesday, April 29, 2008 10:29:46 AM
>  > Subject: [concurrency-interest] ScheduledThreadPoolExecutor and shutdown
>  > permission check.
>  >
>  > I have a STPE that I use in an applet.  At applet shutdown, I'd like to
>  > shutdown
>  > the executor, but alas it requests a Permission check for a
>  > RuntimePermission
>  > that I don't have in an unsigned applet.  It seems kind of silly to
>  > demand this
>  > permission when no other thread management permission exist in the
> JDK for
>  > applets.  Am I missing something in consideration of this issue?
>  >
>  > Gregg Wonderly
>  > _______________________________________________
>  > Concurrency-interest mailing list
>  > Concurrency-interest@...
> <mailto:Concurrency-interest@...>
>  > <mailto:Concurrency-interest@...
> <mailto:Concurrency-interest@...>>
>  > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>  >
>  > ------------------------------------------------------------------------
>  > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
>  > it now.
>  >
> <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 
>
>  >  >
>
>
> ------------------------------------------------------------------------
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
> it now.
> <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 
>  >

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Gregg Wonderly-2]

Joe Bowbeer wrote:

> On Tue, Apr 29, 2008 at 10:29 AM, Gregg Wonderly wrote:
>> I have a STPE that I use in an applet.  At applet shutdown, I'd like to shutdown
>>  the executor, but alas it requests a Permission check for a RuntimePermission
>>  that I don't have in an unsigned applet.  It seems kind of silly to demand this
>>  permission when no other thread management permission exist in the JDK for
>>  applets.  Am I missing something in consideration of this issue?
>>
>
> Interesting.  So the exception is from TPE.shutdown() when it calls
> checkPermission?
>
>     private static final RuntimePermission shutdownPerm =
>         new RuntimePermission("modifyThread");
>
>     SecurityManager security = System.getSecurityManager();
>     if (security != null)
>         security.checkPermission(shutdownPerm);
>
> Before checking to see if the current thread can interrupt the workers
> -- even if none of the workers will actually be interrupted...
>
>     if (security != null) { // Check if caller can modify our threads
>         for (Worker w : workers)
>             security.checkAccess(w.thread);
>     }
>
> The rationale is here
>
>      * [ ... ] we must cooperate
>      * with the security manager (if present), which may implement
>      * policies that make more sense for operations on Threads
>      * than they do for ThreadPools. This requires 3 steps:
>      *
>      * 1. Making sure caller has permission to shut down threads
>      * in general (see shutdownPerm).
>      *
>      * 2. If (1) passes, making sure the caller is allowed to
>      * modify each of our threads. This might not be true even if
>      * first check passed, if the SecurityManager treats some
>      * threads specially. If this check passes, then we can try
>      * to set runState.
>      *
>      * 3. If both (1) and (2) pass, dealing with inconsistent
>      * security managers that allow checkAccess but then throw a
>      * SecurityException when interrupt() is invoked.  In this
>      * third case, because we have already set runState, we can
>      * only try to back out from the shutdown as cleanly as
>      * possible. Some workers may have been killed but we remain
>      * in non-shutdown state (which may entail tryTerminate from
>      * workerDone starting a new worker to maintain liveness.)
>
> What should it do?

The primary issue is that the STPE object reference is the key to being able to
shut things down.  If I have a reference, I should be able to use all functions
of the class, because I am running in the same JVM.  If I was allowed to
create/start something without a permission, it sure seems like I should be able
to stop it with the same level of authorization.  The reachability of Threads in
my ThreadGroup, or in non-root ThreadGroups, is a different issue.  Sure, that
path should be protected from random access without proper permissions.  But, if
I have a reference to TPE, that is a non-global reference (except in some
potential code designs with static instances that are reachable from all threads
with the same class loader/path based visibility), I think it should really use
doPrivileged() on my behalf, and override the asserted authorization I have to
shut things down when I call shutdown.

I'd guess that perhaps someone is thinking of a statically allocated instance
that might be "referenceable" from rogue code, but I don't know.  I just don't
see how the classes behavior provides anything useful from a security control
perspective, especially since this is an instance based mechanism not a static
reference mechanism, where Permission checks can make a lot more sense.

Does anyone have a pointer to existing JVM classes, or a real scenario of where
I might be able to get a reference to a STPE, or any TPE I guess, which I didn't
create, and then should not be able to shut it down?  Those a the cases where a
wrapped Permission check would apply, and a delegate class/method could provide
that service instead of it being in the base class.

Gregg Wonderly
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Endre Stølsvik-6]

Gregg Wonderly wrote:
> Ben Manes wrote:
>> Yes, but my point was that there may not be a need for an explicit
>> shutdown and an implicit one when the applet was stopped would solve
>> most use-cases.
>
> The STPE is used in a class which has hundreds of instances created and
> destroyed over the life of the applet.

While I agree to the problem you're describing (it is downright silly
that threads you been allowed to create and use shouldn't be
*controllable* by you too - I mean, what you're really asking is to have
the threads you've (implicitly) created simply exit their run()
methods), I find this specific usage you describe here somewhat strange:
Why not have one pool that these instances share? I thought a big point
of a threadpool is that thread creation and stopping is rather expensive.

> If I use daemon threads won't they still
> be parked when idle?

Yes, they should.

You could, I guess, use the timeout functionality of the TPEs, so that
they'll die after a (very short) while when the queue is empty.

Endre.
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Tom Hawtin]

Gregg Wonderly wrote:
> I have a STPE that I use in an applet.  At applet shutdown, I'd like to shutdown
> the executor, but alas it requests a Permission check for a RuntimePermission
> that I don't have in an unsigned applet.  It seems kind of silly to demand this
> permission when no other thread management permission exist in the JDK for
> applets.  Am I missing something in consideration of this issue?

If you really needed to do this, you could:
  * Supply a custom ThreadFactory that (weakly) records created threads.
  * Supply a custom queue.
  * On requiring your threads to shutdown, make the queue start throwing
runtime exceptions.
  * Then, interrupt all of your remembered threads.

Tom Hawtin
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Gregg Wonderly-2]

Endre Stølsvik wrote:

> Gregg Wonderly wrote:
>> Ben Manes wrote:
>>> Yes, but my point was that there may not be a need for an explicit
>>> shutdown and an implicit one when the applet was stopped would solve
>>> most use-cases.
>>
>> The STPE is used in a class which has hundreds of instances created
>> and destroyed over the life of the applet.
>
> While I agree to the problem you're describing (it is downright silly
> that threads you been allowed to create and use shouldn't be
> *controllable* by you too - I mean, what you're really asking is to have
> the threads you've (implicitly) created simply exit their run()
> methods), I find this specific usage you describe here somewhat strange:
> Why not have one pool that these instances share? I thought a big point
> of a threadpool is that thread creation and stopping is rather expensive.

The basic problem is that this class is used when the user selects something in
the GUI, to perform work for that selection.  When they select something new, I
need to shut that down and create another instance.  The class really is
standalone.  If I passed in the STPE instance, or had it use a static instance,
then I could leave that one running.  I really dislike having all that linkage
between standalone objects and the users of them.  The thread pool use is not a
publicly describable behavior of the class.  It just does the work and gives the
results and knowing that the STPE is being used, is "under the covers" knowledge.

I guess I'll just have to do something different for this case...

Gregg Wonderly
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[David Holmes-3]

Gregg,

Thank you for the annual "security is broken in TPE" reminder :-) There's a
long history here that started with J2EE security issues and was convoluted
by the fact that the default security manager implementation actually
relaxed security rather than strengthening it - ie it doesn't implement the
installed security policy. We were in a no-win situation and originally used
a direct AccessController.checkPermission call. That upset some folks and it
was later changed to a SecurityManager.checkPermission call - which seemed
to address main concerns.

The bottom line is that the security architecture, as defined, is just
inadequate when it comes to thread creation, control and termination - it's
pretty much all or nothing, so there's no way to discern which threads you
should be allowed to control/modify (though ThreadGroup membership could be
used). There had to be a way to prevent TPE shutdown if the security policy
disallowed it (and in hindsight we perhaps should have gone through the
painful process of trying to get an explicit permission for this - the
reason we didn't was that to do the interrupt() you need the "modifyThread"
permission anyway so we just left it at that). But we couldn't trust the
(default) SecurityManager to enforce that policy hence we made the explicit
permission check.

The consequence of this is that you have the perverse situation where you
can create a TPE (and its threads) but not shut it down. If anyone can see a
resolution to this conundrum we'd be happy to hear it - though simply
disabling any security check is probably not an option (though maybe the
whole J2EE issue is moot now?)

BTW applets thread should be required to have certain permissions for
"modifying" threads outside the applet thread group. Eg you shouldn't be
able to find all threads in the system an interrupt them - but it's been
years since I checked that :)

Cheers,
David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces@...
> [mailto:concurrency-interest-bounces@...]On Behalf Of Gregg
> Wonderly
> Sent: Wednesday, 30 April 2008 3:30 AM
> To: concurrency-interest
> Subject: [concurrency-interest] ScheduledThreadPoolExecutor and
> shutdownpermission check.
>
>
> I have a STPE that I use in an applet.  At applet shutdown, I'd
> like to shutdown
> the executor, but alas it requests a Permission check for a
> RuntimePermission
> that I don't have in an unsigned applet.  It seems kind of silly
> to demand this
> permission when no other thread management permission exist in
> the JDK for
> applets.  Am I missing something in consideration of this issue?
>
> Gregg Wonderly
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Gregg Wonderly-2]

David Holmes wrote:
> Thank you for the annual "security is broken in TPE" reminder :-) There's a
> long history here that started with J2EE security issues and was convoluted
> by the fact that the default security manager implementation actually
> relaxed security rather than strengthening it - ie it doesn't implement the
> installed security policy. We were in a no-win situation and originally used
> a direct AccessController.checkPermission call. That upset some folks and it
> was later changed to a SecurityManager.checkPermission call - which seemed
> to address main concerns.

I still don't understand why you did anything to assert authorization
requirements.  Calls to Thread.interrupt(), Thread.stop(), or manipulation of
the ThreadGroup or Thread objects is still always controlled, explicitly by the
SecurityManager, in some way, where appropriate.  If I have a reference to a
TPE, why can't I call shutdown on that reference and it work?

> The consequence of this is that you have the perverse situation where you
> can create a TPE (and its threads) but not shut it down. If anyone can see a
> resolution to this conundrum we'd be happy to hear it - though simply
> disabling any security check is probably not an option (though maybe the
> whole J2EE issue is moot now?)

I don't pretend to understand the J2EE issue.  I don't use J2EE, at all.  But,
I'd venture to say that a platform class which uses existing APIs should in no
way enforce any authorization which does not represent a new resource that needs
different protection schemes than what the platform (and there are several
related to the type of security manager used) provides.

> BTW applets thread should be required to have certain permissions for
> "modifying" threads outside the applet thread group. Eg you shouldn't be
> able to find all threads in the system an interrupt them - but it's been
> years since I checked that :)

Yes, and that's all the protections that should be enforced.

I'm still struggling to see what use case possibly drives this.  I just can't
think of a reason that I might have a reference to a TPE and it not be right for
me to be able to shut it down.

If I can get into the execution stream, I can throw RuntimeException to stop
threads etc.  Keeping that kind of thing from happening is just part of
designing software that uses classloaders to extend the application in ways that
would allow those other classes to be malicious to your application.

Gregg Wonderly.
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[David Holmes-3]

Gregg,

The use case is that you've been given a reference to an executor that you
are allowed to submit tasks to, but that doesn't give you the right to shut
it down (or arguably to control it in any way). I believe that was the J2EE
scenario.

The problem we had was that if the security policy said that you did not
have permission to "modifyThread", the default SecurityManager
implementation doesn't adhere to that policy - it ignores it unless the
thread is in the root threadgroup - and that's plain wrong. Hence the
explicit permission check.

The thread related permissions are simply far too coarse-grained to provide
any level of fine-grained access control. The SecurityManager should have
provided ThreadGroup based access control but it didn't - and even that
isn't enough for Executor management. So we were left with either no
security, or more security that we really wanted. And the latter won because
at the time security was something that was wanted.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces@...
> [mailto:concurrency-interest-bounces@...]On Behalf Of Gregg
> Wonderly
> Sent: Monday, 5 May 2008 12:52 PM
> To: dholmes@...
> Cc: concurrency-interest; gregg.wonderly@...
> Subject: Re: [concurrency-interest] ScheduledThreadPoolExecutor and
> shutdownpermission check.
>
>
> David Holmes wrote:
> > Thank you for the annual "security is broken in TPE" reminder
> :-) There's a
> > long history here that started with J2EE security issues and
> was convoluted
> > by the fact that the default security manager implementation actually
> > relaxed security rather than strengthening it - ie it doesn't
> implement the
> > installed security policy. We were in a no-win situation and
> originally used
> > a direct AccessController.checkPermission call. That upset some
> folks and it
> > was later changed to a SecurityManager.checkPermission call -
> which seemed
> > to address main concerns.
>
> I still don't understand why you did anything to assert authorization
> requirements.  Calls to Thread.interrupt(), Thread.stop(), or
> manipulation of
> the ThreadGroup or Thread objects is still always controlled,
> explicitly by the
> SecurityManager, in some way, where appropriate.  If I have a
> reference to a
> TPE, why can't I call shutdown on that reference and it work?
>
> > The consequence of this is that you have the perverse situation
> where you
> > can create a TPE (and its threads) but not shut it down. If
> anyone can see a
> > resolution to this conundrum we'd be happy to hear it - though simply
> > disabling any security check is probably not an option (though maybe the
> > whole J2EE issue is moot now?)
>
> I don't pretend to understand the J2EE issue.  I don't use J2EE,
> at all.  But,
> I'd venture to say that a platform class which uses existing APIs
> should in no
> way enforce any authorization which does not represent a new
> resource that needs
> different protection schemes than what the platform (and there
> are several
> related to the type of security manager used) provides.
>
> > BTW applets thread should be required to have certain permissions for
> > "modifying" threads outside the applet thread group. Eg you shouldn't be
> > able to find all threads in the system an interrupt them - but it's been
> > years since I checked that :)
>
> Yes, and that's all the protections that should be enforced.
>
> I'm still struggling to see what use case possibly drives this.
> I just can't
> think of a reason that I might have a reference to a TPE and it
> not be right for
> me to be able to shut it down.
>
> If I can get into the execution stream, I can throw
> RuntimeException to stop
> threads etc.  Keeping that kind of thing from happening is just part of
> designing software that uses classloaders to extend the
> application in ways that
> would allow those other classes to be malicious to your application.
>
> Gregg Wonderly.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest