Bug 741821

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.