[rfc][icedtea-web] Temporary permissions

[Jiri Vanek]

Generally ok, except one important nit:

  final JMenuItem noCmdExec = new JMenuItem(R("STempPermNoExec"));
+        noCmdExec.addActionListener(new TemporaryPermissionsListener(
+                Permissions.READ_LOCAL_FILES, Permissions.WRITE_LOCAL_FILES,
+                Permissions.READ_TMP_FILES, Permissions.WRITE_TMP_FILES,
+                Permissions.READ_PROPERTIES, Permissions.WRITE_PROPERTIES,
+                Permissions.CLIPBOARD_ACCESS, Permissions.PLAY_AUDIO,
+                Permissions.PRINT_DOCUMENTS, Permissions.JAVA_REFLECTION,
+                Permissions.NETWORK_ACCESS));
+        policyMenu.add(noCmdExec);

And similar:
  are - duplicated.


You can push, as similar evil is already done.

However refactoring, asn asap changeset is needed.

the ||| advanced settings button will be encapsulated, so non of its code is duplicated.
You can have your own "extends jbutton" hwhich will do all this logic. And you add jsut insntance of this button to the panes.

Also all the :
new TemporaryPermissionsListener(
+                Permissions.READ_LOCAL_FILES, Permissions.WRITE_LOCAL_FILES,
+                Permissions.READ_TMP_FILES, Permissions.WRITE_TMP_FILES,
+                Permissions.READ_PROPERTIES, Permissions.WRITE_PROPERTIES,
+                Permissions.CLIPBOARD_ACCESS, Permissions.PLAY_AUDIO,
+                Permissions.PRINT_DOCUMENTS, Permissions.JAVA_REFLECTION,
+                Permissions.NETWORK_ACCESS));
+        policyMenu.add(noCmdExec);

should be encapsualted.  Those permissionListeners may be stored in some static class as static constantsand just used as singletons. or not?
If not then they can be provided by some factory methods. But not spred in gui code like this.

Yes, just code celaning, but how it is now, i do not look nicely.

Sorry for troubles:(
   J.




On 03/24/2014 07:05 PM, Andrew Azores wrote:
> On 03/24/2014 12:18 PM, Jiri Vanek wrote:
>> On 03/24/2014 04:55 PM, Andrew Azores wrote:
>>> Hi,
>>>
>>> This patch adds new menu items to the new popup menu where PolicyEditor can be launched. These new
>>> items make it possible to run the current applet sandboxed, but with some additional permissions
>>> added, without having to actually launch PolicyEditor and configure the permissions. These
>>> permissions are also temporary, as opposed to making a custom policy, which persists until you
>>> remove the policy.
>>>
>>> Right now the permission set defined is just the sum of the permissions PolicyEditor can grant via
>>> its checkboxes, and the two options added are No File Access and No Network Access, which are just
>>> that full set minus a few. I'd appreciate input on what other temporary permission options could be
>>> made available.
>>
>> Only Sound
>> Only clipboard
>>
>> ? .. jsut ideas :)
>>
>> Generally I would like to have combinations, which allows to me most of freedom, but protectme aginst gratest evils
>> - fiel accees
>> - network
>> - system.exec and simialr calls (yaaaaaaah!!)
>>
>> and ege sets of above
>> - no fiel accees nor networl
>> - network nor system exec
>> - system.exec nor fileacces
>> - non of those three
>>
>> ....
>> agian - jsut ideas....
>
> Okay, added a bunch like this, including Reflection as we discussed on IRC, and Runtime.exec which is actually FilePermission with execute action apparently (makes sense).
>
>>
>>>
>>> Anyone have ideas on making the popup menu disappear nicely, rather than adding a setVisible call on
>>> it to every action listener we have? And I suppose it should also be forced to disappear when the
>>> dialog is disposed as well. What's the best practice for that?
>>
>> You can try lostfocus (it is actually window inside) or on MouseExited). Each have its pross and cons...
>>
>
> Didn't end up using either, but problem is solved anyway using the show() method rather than setVisible(), I think.

Yes  - may be.