Created attachment 908163 [details] Error Log Description of problem: Crashes on initialisation in Webmin File Manager Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1. Open Webmin - 1.69 2. Open File Manager Actual results: IcedTea-Web Plugin version: 1.5 (fedora-2.fc20-x86_64) Fri Jun 13 00:08:31 EST 2014 net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet. For more information click "more information button". Caused by: net.sourceforge.jnlp.LaunchException: The applet is signed but its manifest specifies Sandbox permissions. This is not yet supported. Try running the applet again, but choose the Sandbox run option. Expected results: Additional info:
Does it work if you choose the Sandbox run option as specified in the message?
Good question I initially saw a setting for sandbox and tried it but it made no change (OpenJDK 1.7) I added JRE 1.8 swapped to it and continued to get the error Then could not find the sandbox setting area Just swapped back to OpenJDK 1.7 using alternatives and now have it operational Must say I am dazed and confused at this stage, there have been updates on the system Current Version is 1.7.0.60-2.4.7.4
Re-assigning to Andrew as he is presently looking adding support for all this.
Hi Wayne, When you say "sandbox setting area", what are you referring to in particular? On the security prompts that appear when you run a signed applet, there should be a new button in 1.5 labelled "Sandbox", next to the old button labelled "Run". This button certainly shouldn't disappear if you switch from Java 7 to 8. This is the button that the message is referring to. When you say you "now have it operational", does this mean that the applet is working for you?
Andrew It is a new clean install I did a week or so ago then updated to latest so I am just getting my head around v20 When I dropped Webmin on it came up with the initialisation error on File Manager I tried 1.8 and now have dropped back to 1.7 and in Control Centre / Iced Tea Web Control Panel / Extended Applet Security I have swapped to Low Security and it works and passes Java.com, Webmin File Manager works etc If I bring Security back up it fails and I then need to change settings to low, log out and back in to resolve it This is a test system I am working with so it is fine for what I am using it for Tell me what you need to look further and I will do what you need and supply the info Re sandbox, I vaguely recall on first initialisation of Wenmin File Manager there was a setting in a screen re sandbox but I cant find any reference to sand box in policy or control panel for Iced Tea now
Ah, yes, if you use Low security setting then it actually skips the check for the Permissions manifest attribute, which is why that allows the applet to run. This is not recommended, however, but it may be useful as a temporary workaround. When you run the applet with High security, does a dialog appear prompting you if you want to run the applet, or does it just immediately fail? If no dialog appears prompting you to run the applet then this probably means you have previously chosen to "Always Trust" the applet, which means it defaults to the "Run" action without presenting the "Sandbox" choice. You can resolve this by opening itweb-settings and selecting Certificates in the left-hand pane. Select Trusted Certificates from the dropdown menu at the top. You will then be presented with a list of signing certificates which you have deemed trustworthy so that applets signed with any of these certificates will be automatically run without prompting you. You will need to determine which certificate corresponds to the applet(s) in question and Remove them from the list. The next time you go to run the applet a security dialog will appear with the aforementioned "Run" and "Sandbox" buttons.
Andrew OK, thanks for the pointer on what to look for Will remove the certificate and re test, anything in particular you need re any errors which come up ? Agree with you my work around would not be good in the real world but it keeps my f20 testing going
Let me know if you're able to make the security dialog appear prior to the applet running under High security. If it doesn't appear then we'll have to figure out why that is. If it does appear, please try running it with the "Run" button, but first uncheck the "Always Trust" checkbox on the dialog. If you do not uncheck the dialog then the security dialog will no longer appear in the future until you re-remove the certificate from itweb-settings as described above. Using the "Run" button, the applet should fail to launch in the same manner as above, but this is just a sanity check. Next, close the applet and retry it again. This time, deslect the "Always Trust" checkbox and click the "Sandbox" run button. This should allow the applet to run successfully. If it does not, then please post the stacktrace and any other information that may come up. This is the method with which you'll need to run the applet, at least until a patch goes in that will properly enable this class of applet to run with the standard "Run" button. Hopefully that update won't take too long for us to make.
Andrew Steps Taken 1/ Opened Iced Tea Control Panel, removed certificate (There are actually 2 certificates * and Jameson Cameron/Comodo CA2) 2/ Opened Firefox/Webmin/File Manager (applet ran on low security without clicking "always trust"), closed Firefox 3/ Changed Security Setting to high - User will be prompted 4/ Opened Firefox/Webmin/File Manager - Security Warning came up, Applet Failed on clicking run, No "Sandbox" button 5/ Checked Firefox Certificate Manager and found the Certificate listed there, deleted it, closed Firefox 6/ Opened Firefox/Webmin/File Manager - No Sandbox option on intial "run" dialogue, second dialogue now appears Untick "Trust" and select "Sandbox", applet then hung on front splash screen (due no permissions ?) Found another certificate exemption in Firefox Certificate Manager/Servers, deleted it This now brings up the "Connection Untrusted Dialogue" on initial opening of Webmin (added exception) Why Webmin is "self signing" on this beats me, never understood it 7/ Opened Firefox/Webmin/File Manager - clicked through first dialogue, with second in advanced sandbox settings selected "all file and properties access" and applet runs 8/ Repeated above without setting advanced and only using sand box, all works including read/write/Create Cant see any policy doc has been created Now unable to generate the "hang" on the initial splash screen when selecting sandbox much to my annoyance Can get another trace re normal run failure but I assume would be the same as I attached at the beginning, let me know if there is anything else you would like me to check
So just to clarify, the applet does work now with the "Always Trust" revoked and using the Sandbox option? Can you provide a screenshot or at least some more description of the dialog that you describe in step "4/"? Yes, if you click "Run" rather than "Sandbox", the stack trace should be identical to the original one you posted. If you "Always Trust" an applet then it simply defaults to the Run choice rather than prompting, so it would be the same result.
Yes it runs with the "Always Trust" revoked and using sandbox It was the certificate in Firefox which was the key to remove to enable the second dialogue with the option for sandbox to appear Yes, if you select run, it fails as before so I have to click through the 2 boxes each time and untick "Always Trust" From my perspective I can see why it should not always simply be run in sandbox but you would have far more knowledge on that than I Have added 2 screenshots as attachments above
Created attachment 909177 [details] First dialogue 2 screenshots for Andrew
Created attachment 909178 [details] Second Dialogue Second screenshot For Andrew
Ah I see. Okay, well I'm glad that it's all sorted out for you then. That first dialog actually is a prompt about trusting the certificate used for an HTTPS network connection, rather than trusting the applet itself, which is why it doesn't present the options to do with permissions granted to the applet. Odd that you had to remove a certificate from Firefox to have the applet trust dialog appear though. The second dialog is the one actually asking if you trust the applet itself, and so it does present the permissions options. And yes, I know it's a bit annoying that there are two dialogs to click through, and you also have to untick the check boxes first :( I do have a patch in progress that makes the "sandboxing" possible to have happen automatically, which solves all the annoyance here. I proposed a while ago to also uncheck the boxes by default, but it was voted for it to remain as it is now. With the automatic sandboxing patch it's less of a concern anyway. Last few questions I have about what you did to get the applet working. In step 7/, do you mean you selected the temporary permissions preset available through a small dropdown menu which appears when clicking the "menu overflow (three horizontal bars)" button next to the Sandbox button? Or did you actually open PolicyEditor and set the permissions there? You can check if the permissions were applied persistently by looking in the file ~/.config/icedtea-web/security/java.policy. If this file doesn't exist or doesn't contain any entry granting the Webmin applet file and properties permissions, then the permissions were only applied temporarily, which applies to only the current run of the applet. Restarting the applet even without closing and reopening the browser should result in a second run not being granted the additional permissions unless you do so again explicitly. Peristently granting these permissions is what the policy file and PolicyEditor exist to provide.
Yes in step 7 I used the drop down box rather than the policy editor as I felt it stuck to the way it was all designed, one odd thing was it seemed the applet had read/write over the file system even where I selected read only first time round then on a second opening I selected read/write now I simply click sandbox without explicit setting of those permissions ~/.config/icedtea-web/security/java.policy exists but policy editor does not show any policies so no persistant settings were done You are correct, second and third opening of file manager without closing browser requires clicking through the dialogiue boxes
PolicyEditor is actually the primary intended method, the temporary permissions were just added as a nicety afterward ;). If you can reproduce the part where the applet was granted read/write when you only wanted to give it read access then that would be greatly appreciated as that's a serious issue. There was a bug potentially related to this however where if you left "Always Trust" selected and chose a temporary permission preset, then unchecked "Always Trust" and selected a different preset, then the union of those two presets would actually be applied. This has since been fixed but has not yet made it into a release. Perhaps you inadvertently did this?
closing as "not a bug" since this is more of a local configuration issue than a bug. If you can reproduce the scenario where the applet is granted permissions which it should not have then please open a new bug for that. Thanks.