Created attachment 942290 [details] Screenshot of error message Description of problem: No web applets work. Whenever I try to start one, an error message pops up, complaining about missing config directories that cannot be read/written properly. Version-Release number of selected component (if applicable): icedtea-web-1.5.1-0.fc20.x86_64 How reproducible: 100% Steps to Reproduce: 1. Open in Firefox: http://www.java.com/en/download/installed.jsp?detect=jre 2. Accept any security prompts Actual results: An error message shows up complaining about missing directories that cannot be read/written properly. Expected results: The applet should load. Additional info: If I manually create the directories that the message complains about with "mkdir -p ~/.cache/icedtea-web/{cache,pcache,tmp} ~/.config/icedtea-web/log", the error message gets smaller, but the applets still fails to load. The error message shown in this case, is: Your configuration directory /home/tore/.cache/icedtea-web/cache can not be read/written properly. Your configuration directory /home/tore/.cache/icedtea-web/pcache can not be read/written properly. Your configuration directory /home/tore/.config/icedtea-web/log can not be read/written properly. Your configuration directory /home/tore/.cache/icedtea-web/tmp can not be read/written properly. However all of these directories exist and are writable by my user. I've also tried chmod 777'ing them. This doesn't help; the error message remains the same.
(In reply to Tore Anderson from comment #0) > Created attachment 942290 [details] > Screenshot of error message > > Description of problem: > > No web applets work. Whenever I try to start one, an error message pops up, > complaining about missing config directories that cannot be read/written > properly. > > Version-Release number of selected component (if applicable): > > icedtea-web-1.5.1-0.fc20.x86_64 > > How reproducible: > > 100% > > Steps to Reproduce: > 1. Open in Firefox: http://www.java.com/en/download/installed.jsp?detect=jre > 2. Accept any security prompts > > Actual results: > > An error message shows up complaining about missing directories that cannot > be read/written properly. > > Expected results: > > The applet should load. > > Additional info: > > If I manually create the directories that the message complains about with > "mkdir -p ~/.cache/icedtea-web/{cache,pcache,tmp} > ~/.config/icedtea-web/log", the error message gets smaller, but the applets > still fails to load. The error message shown in this case, is: > > Your configuration directory /home/tore/.cache/icedtea-web/cache can not be > read/written properly. > Your configuration directory /home/tore/.cache/icedtea-web/pcache can not be > read/written properly. > Your configuration directory /home/tore/.config/icedtea-web/log can not be > read/written properly. > Your configuration directory /home/tore/.cache/icedtea-web/tmp can not be > read/written properly. > > However all of these directories exist and are writable by my user. I've > also tried chmod 777'ing them. This doesn't help; the error message remains > the same. Hello, Could you open 'itweb-settings' (should work in command line) and: Debugging Tab: Enable Debugging Enable logging to File Java Console: Show on Startup Please try to open an applet and attach the logs produced to this bug. As well, a Java Console should appear. In this console please 'Show Details->Copy all Text(plain) and paste the text into a text file and attach these to the bug as well. Regards,
Created attachment 942558 [details] Debugging log from java console, as requested Attached is the debugging log from the java console. It never stopped growing, so I just copied the text at some point. Seems it was the same error that kept repeating in an endless loop. Nothing showed up in ~/.config/icedtea-web/log/, even though the directory was pre-created and writable. Perhaps not so strange, considering that one of the error messages in the pop-up was relating to this specific directory not being able to be read/written correctly. All directories were pre-created, hence the popup only showed the four warnings I mentioned earlier: Your configuration directory /home/tore/.cache/icedtea-web/cache can not be read/written properly. Your configuration directory /home/tore/.cache/icedtea-web/pcache can not be read/written properly. Your configuration directory /home/tore/.config/icedtea-web/log can not be read/written properly. Your configuration directory /home/tore/.cache/icedtea-web/tmp can not be read/written properly. Tore
Created attachment 942708 [details] Use of ls -l in terminal
(In reply to Tore Anderson from comment #2) > Created attachment 942558 [details] > Debugging log from java console, as requested > > Attached is the debugging log from the java console. It never stopped > growing, so I just copied the text at some point. Seems it was the same > error that kept repeating in an endless loop. > > Nothing showed up in ~/.config/icedtea-web/log/, even though the directory > was pre-created and writable. Perhaps not so strange, considering that one > of the error messages in the pop-up was relating to this specific directory > not being able to be read/written correctly. > > All directories were pre-created, hence the popup only showed the four > warnings I mentioned earlier: > > Your configuration directory /home/tore/.cache/icedtea-web/cache can not be > read/written properly. > Your configuration directory /home/tore/.cache/icedtea-web/pcache can not be > read/written properly. > Your configuration directory /home/tore/.config/icedtea-web/log can not be > read/written properly. > Your configuration directory /home/tore/.cache/icedtea-web/tmp can not be > read/written properly. > > Tore (In reply to Tore Anderson from comment #2) > Created attachment 942558 [details] > Debugging log from java console, as requested > > Attached is the debugging log from the java console. It never stopped > growing, so I just copied the text at some point. Seems it was the same > error that kept repeating in an endless loop. > > Nothing showed up in ~/.config/icedtea-web/log/, even though the directory > was pre-created and writable. Perhaps not so strange, considering that one > of the error messages in the pop-up was relating to this specific directory > not being able to be read/written correctly. > > All directories were pre-created, hence the popup only showed the four > warnings I mentioned earlier: > > Your configuration directory /home/tore/.cache/icedtea-web/cache can not be > read/written properly. > Your configuration directory /home/tore/.cache/icedtea-web/pcache can not be > read/written properly. > Your configuration directory /home/tore/.config/icedtea-web/log can not be > read/written properly. > Your configuration directory /home/tore/.cache/icedtea-web/tmp can not be > read/written properly. > > Tore Hmm. In itweb-settings you should be able to change the location of the log file. Could you change it to say ~/ (or a location of your choosing) in the hopes that we are able to read/write there, and then rerun the website. As well, could you attach a screenshot of your terminal with the command 'ls -l' in the folder ~/.cache/icedtea-web/ I have attached an example from my machine where the command is run in both ~/.config/icedtea-web and ~/.cache/icedtea-web. Some other things you can try: Use 'su -' in terminal to login as root and run the website from that terminal. You will need to know the root password in order to do this E.g. in terminal $ su - $ firefox http://www.java.com/en/download/installed.jsp?detect=jre itweb-settings also allows you to set the cache directory. (itweb-settings : Cache) Try changing it to a location of your choosing and see if the errors still appear. This doesn't solve the issue with the ~/.config not being readable though so this has a very low chance of helping;.. As well, what process did you go through to acquire icedtea-web-1.5.1-0.fc20.x86_64? At this point I am wondering if a 'reinstall' might help. Regards,
Created attachment 942848 [details] audit.log from when a Java applet freezes Firefox Hello, Changing the debugging log file location did work to some extent, in that a log file did show up. Firefox did immediately freeze completely as soon as a Java applet was loaded, though. But the fact that log locations outside of my $HOME did work was the clue I needed to find the root cause of this, which appears to be the combination of having an encrypted home directory plus SELinux in its default enforcing mode. When this is the case, I get the freeze I mentioned. At the same time, a number of denials are logged to /var/log/audit/audit.log (see attachment). If I set SELinux to the permissive mode (with "echo 0 > /sys/fs/selinux/enforce"), Java applets does work correctly. The SELinux boolean "use_ecryptfs_home_dirs" is set to "on". So it would appear that some extra SELinux policy is required in order to make Icedtea-web work correctly with encrypted home directories. I assume this information should enable you to reproduce the issue yourself and that no further information is needed from me, please let me know if this is not the case. Tore
Created attachment 943528 [details] Example of encrypted and unencrypted files labels. (In reply to Tore Anderson from comment #5) > Created attachment 942848 [details] > audit.log from when a Java applet freezes Firefox > > Hello, > > Changing the debugging log file location did work to some extent, in that a > log file did show up. Firefox did immediately freeze completely as soon as a > Java applet was loaded, though. > > But the fact that log locations outside of my $HOME did work was the clue I > needed to find the root cause of this, which appears to be the combination > of having an encrypted home directory plus SELinux in its default enforcing > mode. When this is the case, I get the freeze I mentioned. At the same time, > a number of denials are logged to /var/log/audit/audit.log (see attachment). > If I set SELinux to the permissive mode (with "echo 0 > > /sys/fs/selinux/enforce"), Java applets does work correctly. The SELinux > boolean "use_ecryptfs_home_dirs" is set to "on". > > So it would appear that some extra SELinux policy is required in order to > make Icedtea-web work correctly with encrypted home directories. > > I assume this information should enable you to reproduce the issue yourself > and that no further information is needed from me, please let me know if > this is not the case. > > Tore Hello, Thank you for the audit.log and explanation. When examining the log I noticed that the Context for your encrypted files was: tcontext=unconfined_u:object_r:user_home_t:s0 The reason for this issue is that mozilla plugins do not have access to user_home_t targets. However I believe encrypted files and directories (using ecryptfs) should have a type of 'ecrypt_fs_t' This is shown in the attached .png. Here I have three terminals. Top-left showing the Context for an unencrypted .cache folder, top-right showing the Context for an encrypted .cache folder, and bottom-left showing my encrypted .Private folder. With this encrypted home directory and "use_ecryptfs_home_dirs" set to true, I was unable to reproduce the error. I suggest restoring the context using 'restorecon' (e.g. "restorecon -R -v DIR"). Changing your Contexts to 'ecrypt_fs_t' will solve the issue. If this does not work, using the latest ecryptfs-utils and the ecryptfs-migrate-home command should let you build a home directory with the updated Context labels. As well, you should make sure the SELinux Policy boolean 'unconfined_mozilla_plugin_transition' is set to false: "sudo setsebool -P unconfined_mozilla_plugin_transition 0" Please let me know how it goes. Regards,
Hi Jie, and thank you. I touched /.autorelabel and rebooted, this should relabel the entire filesystem. After the reboot, all the files in my $HOME hade the context "system_u:object_r:ecryptfs_t:s0" (like yours), while all the files in my $HOME/.Private have the context "unconfined_u:object_r:user_home_t:s0" - unlike yours. I double-checked by creating a new user and doing ecryptfs-migrate-home, and the result was the same, the encrypted files in ~/.Private are all labelled with "unconfined_u:object_r:user_home_t:s0". There is however some progress. After relabelling, the www.java.com's JRE detection applet does run, IFF I have pre-created the four directories it complains about. It will still pop up an error complaining about the directories not being able to read/written correctly, but after dismissing this error message, the applet appears to run normally. If the directories are not pre-created, the error message is like the one I already attached to my initial report, and the applet fails to load after dismissing it. I'm just mentioning tis as a FYI, as disabling the "unconfined_mozilla_plugin_transition" sebool does appear to be a complete fix. Whith this change in place, the applet loads and runs without error messages even when the four directories are not pre-created, and no errors show up in audit.log. That's good enough for me, so thanks again! Tore