18 Dec
2011
18 Dec
'11
4:29 p.m.
Hi everyone,
I've tried to use openjdk 6 and the corresponding icedtea Firefox plugin
as a replacement for sun-java-6 on Ubuntu 11.10 for accessing BCEE's
S-NET site. I get the infamous message: "exception:
java.security.AccessControlException : access denied" and the applet
does not start. In the same situation, during the first access to the
site, the old sun java plugin ran a popup asking whether the user would
grant permission to execute the applet and updated its config
accordingly. This is apparently missing in icedtea's (or openjdk's?)
setup.
Of course, I can make it work by writing a ~/.java.policy with
grant {
permission java.security.AllPermission;
};
but the security implications are severe, to say the least.
Any advice?
Thanks
Alain
31 Dec
31 Dec
9:14 a.m.
Hello Alain,
On 2011-12-18 17:29, Alain Louge wrote:
Hi everyone,
I've tried to use openjdk 6 and the corresponding icedtea Firefox plugin
as a replacement for sun-java-6 on Ubuntu 11.10 for accessing BCEE's
S-NET site. I get the infamous message: "exception:
java.security.AccessControlException : access denied" and the applet
does not start. In the same situation, during the first access to the
site, the old sun java plugin ran a popup asking whether the user would
grant permission to execute the applet and updated its config
accordingly. This is apparently missing in icedtea's (or openjdk's?)
setup.
A, so that is the reason why openjdk fails with so many applets. Thanks
for having found this out.
Of course, I can make it work by writing a ~/.java.policy with
grant {
permission java.security.AllPermission;
};
but the security implications are severe, to say the least.
Apparently, it is possible to grant permission by codebase (i.e. where
applet has been downloaded from), rather than globally:
grant codeBase "https://www.bcee.lu/..." {
permission java.security.AllPermission;
};
(change the URL as appropriate, the codebase should be listed somewhere
on the page that calls the applet, or would by default be that page
itself or its directory).
Still grants all permissions to the BCEE applet, but at least now it is
limited to this applet, so the implication is far less sever now.
Any advice?
Thanks
Alain
Regards, and have a nice slide into the new Year!
Alain
10:48 p.m.
Le samedi 31 décembre 2011 à 10:14 +0100, Alain Knaff a écrit :
A, so that is the reason why openjdk fails with so
many applets. Thanks
for having found this out.
Always a pleasure :-)
Apparently, it is possible to grant permission by
codebase (i.e. where
applet has been downloaded from), rather than globally:
grant codeBase "https://www.bcee.lu/..." {
permission java.security.AllPermission;
};
Just tried with
grant codeBase "https://www.bcee.lu/*" {
permission java.security.AllPermission;
}
grant codeBase "https://bcee.snet.lu/*" {
permission java.security.AllPermission;
};
since I suspect either URL may be involved. I also tried different
wildcards and other variants, and I think I have avoided caching issues,
but it still doesn't work, and there are few things on earth I loathe as
much as digging into java code... (well, fortran qualifies as a worthy
second). The only thing that seems to work is:
grant {
permission java.security.AllPermission;
};
In any case, the true problem lies with laymen, who will simply state
that "linux doesn't work", as usual. And in this case, they will be
right (especially with ubuntu's recent automatic removal of the sun java
plugin). We can't ask them to edit a config file. Why doesn't icedtea
just spit out a popup like sun java?...
In any case, I find it hard to believe that no one coding for openjdk
has met the problem; it must on the contrary be pervasive, as you hinted
yourself. I tried to google for an explanation, to no avail.
Regards, and have a nice slide into the new Year!
Thanks, and a happy new year too !
Alain
5056
days inactive
5069
days old
2 comments
2 participants
participants (2)
-
Alain Knaff -
Alain Louge