Description of problem: The Banco do Brasil (http://www.bb.com.br/) online banking depends on a Java "security module" (módulo de segurança), which runs as an applet within the browser. This "security module" fails to load unless an empty /etc/.java/.systemPrefs is created. Apparently, it is the preferences code within the Java runtime library that breaks if this directory does not exist. Creating this directory (nothing more than a simple "sudo mkdir -p /etc/.java/.systemPrefs") was enough to fix the problem. To prevent this hard-to-diagnose problem on an important use case, this empty directory should be created by default. Alternatively, the Java runtime library should be fixed to not depend on it to work correctly. Version-Release number of selected component (if applicable): java-1.6.0-openjdk-1.6.0.0-59.1.10.3.fc15.x86_64 icedtea-web-1.0.4-1.fc15.x86_64 firefox-6.0.2-1.fc15.x86_64 How reproducible: Every time. Steps to Reproduce: 1. If you successfully loaded the applet before, erase the relevant files in ~/.java and ~/.icedtea (it is easier to erase both directories completely). 2. Make sure /etc/.java does not exist. 3. Open Firefox and make sure the IcedTea web plugin is enabled. 4. Go to http://www.bb.com.br/ 5. On the header of the site, there are fields to put your branch and account number. Leave both blank and press the OK button (it does not matter what you put in them, it will try to load the "security module" anyways). 6. Accept the security warning, if it shows one. Actual results: 1. It redirects to a "Problemas na instalação do Módulo de Segurança" error page. 2. On Firefox's console output (either stdout or stderr), the following shows: java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.10.3) (fedora-59.1.10.3.fc15-x86_64) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) 27/09/2011 23:57:59 java.util.prefs.FileSystemPreferences$3 run WARNING: Could not create system preferences directory. System preferences are unusable. 27/09/2011 23:57:59 java.util.prefs.FileSystemPreferences$2 run INFO: Created user preferences directory. Expected results (what happens if /etc/.java/.systemPrefs exists): 1. It redirects to a page where you can enter your branch and account number and your online banking password. 2. On Firefox's console output (either stdout or stderr), the following shows: java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.10.3) (fedora-59.1.10.3.fc15-x86_64) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) 28/09/2011 00:06:07 java.util.prefs.FileSystemPreferences$2 run INFO: Created user preferences directory. 28/09/2011 00:06:12 java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode WARNING: Could not lock System prefs. Unix error code 0. 28/09/2011 00:06:14 java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode WARNING: Could not lock System prefs. Unix error code 0. Additional info: I found the solution (to create an empty /etc/.java/.systemPrefs directory) in the following message: https://groups.google.com/group/archlinux-br/msg/b3ef217c9da63512 Somewhere else in the same thread, the following bug report was created: https://bugs.archlinux.org/task/18872
java.util.prefs.FileSystemPreferences is part of the JDK. It hardcodes looking up system preferences at /etc/.java/.systemPrefs. If the lookup (which creates the directories if it can) fails then it returns null. My first gut feeling is to say that this is a bug in the applet. It should deal with null system preferences. But it doesnt. It's not like the applet can write to it even if it exists. I tested with a blank /etc/.java/.systemPrefs/ directory and the applet works, so it does not need any data from there either. In other words, the applet does not need the contents; it just fails when it's null. But I could also argue this is a bug in the java-1.6.0-openjdk. It is this openjdk code which tries to lookup preferences in a non-existing location. Perhaps the rpm should create the directory /etc/.java/.systemPrefs on install? On a side note, the hidden directory in /etc/ looks like a hack. Perhaps we can change the location to /etc/java/system-prefs or something? /etc/java/ already exists (owned by jpackage-utils).
Is it possible to make the JDK crash using public apis if /etc/.java/.systemPrefs/ is missing?
Shouldn't/Couldn't the applet viewer/plugin install its own PreferencesFactory for use by applets?
(In reply to comment #3) > Shouldn't/Couldn't the applet viewer/plugin install its own PreferencesFactory > for use by applets? Should it? Is this documented somewhere? Only signed/trusted applets can actually use the PreferencesFactory. I cant see why we would deny the Preferences corresponding to the standard system root to them.
(In reply to comment #2) > Is it possible to make the JDK crash using public apis if > /etc/.java/.systemPrefs/ is missing? Not in any way I can see. It just returns a Preferences object that will throw exceptions (mostly BackingStoreException from what I can see) or return null on a number of operations. Of course, uncaught exceptions may terminate the thread where the exception occurs.
(In reply to comment #1) > My first gut feeling is to say that this is a bug in the applet. It should deal > with null system preferences. But it doesnt. It's not like the applet can write > to it even if it exists. I tested with a blank /etc/.java/.systemPrefs/ > directory and the applet works, so it does not need any data from there either. > In other words, the applet does not need the contents; it just fails when it's > null. Yeah, I also tested with an empty /etc/.java/.systemPrefs directory and it worked. I did not try putting anything there, only creating the empty directory (and its parent). > But I could also argue this is a bug in the java-1.6.0-openjdk. It is this > openjdk code which tries to lookup preferences in a non-existing location. > Perhaps the rpm should create the directory /etc/.java/.systemPrefs on install? I also think this. The java-1.6.0-openjdk package should create this directory, and perhaps some magic files within it (see below). > On a side note, the hidden directory in /etc/ looks like a hack. Perhaps we can > change the location to /etc/java/system-prefs or something? /etc/java/ already > exists (owned by jpackage-utils). That could cause problems if a user already has anything at /etc/.java/.systemPrefs (unless the package moved the directory to the new name on install or update). It would also diverge from upstream. Other than that, I do not see many problems, since nothing should look there directly (everyone should go through the Java standard library). And I agree that having it be a hidden directory within a hidden directory within /etc is both ugly and confusing. ---- I took a look today at a Ubuntu 10.04 LTS system, and here is what I found there: $ ls -lRa /etc/.java /etc/.java: total 20 drwxr-xr-x 3 root root 4096 2011-01-13 15:46 . drwxr-xr-x 151 root root 12288 2011-09-28 10:31 .. drwxr-xr-x 2 root root 4096 2011-01-13 15:46 .systemPrefs /etc/.java/.systemPrefs: total 8 drwxr-xr-x 2 root root 4096 2011-01-13 15:46 . drwxr-xr-x 3 root root 4096 2011-01-13 15:46 .. -rw-r--r-- 1 root root 0 2011-01-13 15:46 .system.lock -rw-r--r-- 1 root root 0 2011-01-13 15:46 .systemRootModFile So, it has hidden files within the hidden subdirectory within the hidden directory. I do not know what these files are for, but there probably is a reason for both being there. It might be a good idea to find out what these files are for, and whether they should also be created together with the directory.
(In reply to comment #5) > (In reply to comment #2) > > Is it possible to make the JDK crash using public apis if > > /etc/.java/.systemPrefs/ is missing? > > Not in any way I can see. It just returns a Preferences object that will throw > exceptions (mostly BackingStoreException from what I can see) or return null on > a number of operations. Of course, uncaught exceptions may terminate the thread > where the exception occurs. OK, if the access is already guarded by the SecurityManager then I guess everything is fine. I don't know of anything documenting giving Applets their own (private) Preferences. It just seemed like a nice idea, so applets could have their own preferences stored somewhere instead of reusing the user or root ones. There is a mechanism for overriding the default PreferencesFactory, that is why I thought it might be a good idea. But as far as I know it isn't required.
Created attachment 525641 [details] create and own /etc/.java/.systemPrefs
java-1.6.0-openjdk-1.6.0.0-61.1.10.4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-61.1.10.4.fc15
java-1.6.0-openjdk-1.6.0.0-61.1.10.4.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-61.1.10.4.fc16
Package java-1.6.0-openjdk-1.6.0.0-61.1.10.4.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing java-1.6.0-openjdk-1.6.0.0-61.1.10.4.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16586/java-1.6.0-openjdk-1.6.0.0-61.1.10.4.fc15 then log in and leave karma (feedback).
java-1.6.0-openjdk-1.6.0.0-61.1.10.4.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
thank you for making braindead hidden folders because a broken app somewhere in brasil and require changes for rootkithunter it is generally from the viewpoint of a transparent and clear system idiotic to generate hidden folders unter /etc [root@srv-rhsoft:~]$ cat /etc/rkhunter.conf.local ALLOWHIDDENDIR=/etc/.java
The braindead requirement is the fault of Java for having used that directory in the first place. The packaging change is simply trying to maximize compatibility and reduce breakage.
java-1.6.0-openjdk-1.6.0.0-61.1.10.4.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.