[icedtea-web] RFC: get the security handler in a privileged operation
Omair Majid
omajid at redhat.com
Mon Oct 25 11:09:59 PDT 2010
On 10/25/2010 01:45 PM, Deepak Bhole wrote:
> * Omair Majid<omajid at redhat.com> [2010-10-25 13:37]:
>> Hi,
>>
>> The attached patch ensures that posting a security message is done
>> with full privileges. This is being done already in the EDT
>> (EventDispatchThread) case, but not in the non-EDT case.
>>
>
> Are there any problems if it doesn't have full permissions? I'd rather
> give it less permissions than more unless really needed...
>
JNLPRuntime.getSecurityDialogHandler() throws a SecurityException if the
caller does not have AllPerissions. If SecurityWarning.* is ever called
from something which does not have full permissions, it will fail.
However, on further going through code, everything that currently calls
SecurityWarning.* is (as far as I can tell) fully privileged (is this a
good idea?). So avoiding this doPrivileged() should not cause a problem.
> If not needed, the doProvileged() from EDT should be removed as well.
>
I will do that then.
> Deepak
>
>> ChangeLog:
>> 2010-10-25 Omair Majid<omajid at redhat.com>
>>
>> * netx/net/sourceforge/jnlp/security/SecurityWarning.java
>> (getUserResponse): Get the SecurityDialogHandler with full
>> prvileges.
>>
>> Any objections?
>>
>> Thanks,
>> Omair
>
>> diff -r e9910d92b046 netx/net/sourceforge/jnlp/security/SecurityWarning.java
>> --- a/netx/net/sourceforge/jnlp/security/SecurityWarning.java Mon Oct 25 12:14:33 2010 -0400
>> +++ b/netx/net/sourceforge/jnlp/security/SecurityWarning.java Mon Oct 25 13:31:30 2010 -0400
>> @@ -278,7 +278,13 @@
>> */
>> message.toDispose = null;
>> message.lock = new Semaphore(0);
>> - JNLPRuntime.getSecurityDialogHandler().postMessage(message);
>> + AccessController.doPrivileged(new PrivilegedAction<Void>() {
>> + @Override
>> + public Void run() {
>> + JNLPRuntime.getSecurityDialogHandler().postMessage(message);
>> + return null;
>> + }
>> + });
>>
>> boolean done = false;
>> while (!done) {
>
More information about the distro-pkg-dev
mailing list