Bug 741821 - /etc/.java/.systemPrefs directory missing breaks Banco do Brasil online banking
/etc/.java/.systemPrefs directory missing breaks Banco do Brasil online banking
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk (Show other bugs)
15
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Omair Majid
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-27 23:15 EDT by Cesar Eduardo Barros
Modified: 2011-12-23 17:19 EST (History)
10 users (show)

See Also:
Fixed In Version: java-1.6.0-openjdk-1.6.0.0-61.1.10.4.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-23 17:19:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
create and own /etc/.java/.systemPrefs (801 bytes, patch)
2011-09-29 16:35 EDT, Omair Majid
no flags Details | Diff

  None (edit)
Description Cesar Eduardo Barros 2011-09-27 23:15:45 EDT
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
Comment 1 Omair Majid 2011-09-28 14:50:39 EDT
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).
Comment 2 Deepak Bhole 2011-09-28 15:15:32 EDT
Is it possible to make the JDK crash using public apis if /etc/.java/.systemPrefs/ is missing?
Comment 3 Mark Wielaard 2011-09-28 15:25:31 EDT
Shouldn't/Couldn't the applet viewer/plugin install its own PreferencesFactory for use by applets?
Comment 4 Omair Majid 2011-09-28 17:39:10 EDT
(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.
Comment 5 Omair Majid 2011-09-28 18:00:02 EDT
(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.
Comment 6 Cesar Eduardo Barros 2011-09-28 18:37:32 EDT
(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.
Comment 7 Mark Wielaard 2011-09-29 03:17:47 EDT
(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.
Comment 8 Omair Majid 2011-09-29 16:35:06 EDT
Created attachment 525641 [details]
create and own /etc/.java/.systemPrefs
Comment 9 Fedora Update System 2011-11-28 14:38:51 EST
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
Comment 10 Fedora Update System 2011-11-28 14:42:40 EST
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
Comment 11 Fedora Update System 2011-11-29 20:55:33 EST
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).
Comment 12 Fedora Update System 2011-12-12 17:03:34 EST
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.
Comment 13 Harald Reindl 2011-12-21 12:15:50 EST
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
Comment 14 Deepak Bhole 2011-12-21 12:56:36 EST
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.
Comment 15 Fedora Update System 2011-12-23 17:19:32 EST
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.

Note You need to log in before you can comment on or make changes to this bug.