[rfc][icedtea-web][icedtea-web-1.5.2] allow also skip of permissions attribute check in case of disabled attributes check

[Jiri Vanek]

On 11/24/2014 05:06 PM, Jie Kang wrote:
>
>
> ----- Original Message -----
>> Hi!
>>
>> The permission attribute is still incompletely implemented and mixed
>> signatures apps are suffering not working with itw. by specifing it.
>>
>> The implementation troubles ate in ITW two:
>>    - it can happen that application is loaded by various jnlpfiles
>>      => one jnlp file is signed, secondnot : however whole application is
>>      signed- so check in second jnlp file on sandbox attribute will finish by
>>      error.
>>      - fix it to have two kinds of attribute checkers - one jnlp file
>>      specific, and one global for whole app. Some attibutes are then checked
>>      globaly, some only on iven jnlpfile
>>    - the applictaion can be loaded by several classloaders each of them with
>>    differet permissions. This is real cause of issues with ^ and I do not
>>    know cure on it.
>>
>>
>> The reproducers are all jogam or joglor .... applets on
>> http://icedtea.classpath.org/wiki/IcedTea-Web-Tests .
>>
>> As for head - I'm working on oflfine integration of applets, and it is quite
>> blocker. As for 1.5 jog* people have already reported this (got lost...) and
>> we should make thi swork for them at least by this workarround.
>>
>> J.
>>
>> ok to head and 1.5?
>>
>> diff -r f1586e8af6b9
>> netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java
>> --- a/netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java	Wed
>> Nov 19 18:33:56 2014 +0100
>> +++ b/netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java	Sat
>> Nov 22 15:53:38 2014 +0100
>> @@ -75,15 +75,14 @@
>>        }
>>
>>        void checkAll() throws LaunchException {
>> -        checkPermissionsAttribute();
>>            if (isCheckEnabled()) {
>> +            checkPermissionsAttribute();
>>                checkTrustedOnlyAttribute();
>>                checkCodebaseAttribute();
>>                checkPermissionsAttribute();
>>                checkApplicationLibraryAllowableCodebaseAttribute();
>>            } else {
>> -
>> OutputController.getLogger().log(OutputController.Level.WARNING_ALL,
>> "Manifest attribute checks are disabled."
>> -                    + " The Permissions attribute will be enforced but other
>> manifest attributes will be ignored.");
>> +
>> OutputController.getLogger().log(OutputController.Level.WARNING_ALL,
>> "Manifest attribute checks are disabled.");
>>            }
>>        }
>
>
> Hello,
>
> It would be great if aazores could review this as I believe his changeset is being modified here.

yes :( I wrote him At friday when I found the bug even a bit more descriptive email... Hoping for 
answer.. :(
>
> My only concern is that for Very High and High security levels, the permissions attribute is checked.
this

>
> This change makes it so the permissions attribute is now no longer always checked for Low security levels, yes? This seems fine as a workaround given [1]. However, with all of these workarounds, I am worried that we will never actually fix the issues :\
and this

>

are - I hope - both incorrect conclusions. The attributes are checked always, no meter of 
security[1] level.

They are not checked, only and if and only if [1]:
deployment.manifest.attributes.check=false
>
> [1] http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#permissions
>    For the Medium (I think for us this is Low) security level, if the Permissions attribute is not present, then the security prompt contains a yellow warning about the missing attribute, and the permissions level requested by the RIA is used.
>
>
[1]
   public static boolean isCheckEnabled() {
         final String deploymentProperty = 
JNLPRuntime.getConfiguration().getProperty(DeploymentConfiguration.KEY_ENABLE_MANIFEST_ATTRIBUTES_CHECK);
         return Boolean.parseBoolean(deploymentProperty);
     }


Thanx for check!


J.