JDK-4751177 : Preferences storage placed unavailable to non-root users
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux
  • CPU: x86
  • Submitted: 2002-09-20
  • Updated: 2019-05-15
  • Resolved: 2002-11-04
Related Reports
Relates :  
Description

Name: gm110360			Date: 09/20/2002


FULL PRODUCT VERSION :
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)


FULL OPERATING SYSTEM VERSION :
Linux 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686
unknown (SuSE 8.0)
  
  
ADDITIONAL OPERATING SYSTEMS :
any Unix-like system

EXTRA RELEVANT SYSTEM CONFIGURATION :
J2SDK is stored on NFS-based place (below /usr/local)

A DESCRIPTION OF THE PROBLEM :
Java 1.4 introduced the preferences API. It stores data in
certain files on the system (and hides this from the
user).
 
The storage position is either below the install directory
or (if the install directory is remotely mounted, e.g. by
NFS) below /etc. Both locations are normally systemwide
and only writeable by root. So, if you run your Java
programs as other user, you get arbitrary error messages
from the java.util.prefs package.
 
As Unix is a multi-user system, the whole idea of having a
global file for preferences storage is wrong, in my
opinion. Preferences should be stored in $HOME/.java by
default, and it should be possible to adjust this place by
an environment variable. This would lead to the
preferences being user-dependent which is the only
sensible way of doing things in Unix, as I see it.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Install JDK/JRE 1.4(.1) as root in a systemwide
directory
2. Run a Java Swing application (Swing happens to use the
Preferences API somewhere)
3. Be happy with the error messages.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expecting: JVM/java.utils.prefs should create files below
user-owned storage segments, e.g. $HOME/.java
  
Actual: JVM/java.util.prefs tries to create files below
$JAVAHOME/.java or /etc/.java which leads to error
messages due to being unable to create the files or
directories. Reason: The global file structures are not
writeable by the non-root user.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
20.09.2002 18:15:00 java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush system prefs: java.util.prefs.BackingStoreException:
Couldn't get file lock.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
- Make .java directory world writeable. Problem: Only the
first user will be able to work with preferences. And
admin's nightmare, of course (below /etc...)
  
- Install JRE/JDK for each user locally. Ridiculous and
works only if home directory is not mounted via NFS.
  
- Write a new Preferences implementation. But why
reinventing the wheel?
  
- Ignore the warnings. But they are annoying and you
cannot use the Preferences API on Unix.
(Review ID: 164796) 
======================================================================

Comments
EVALUATION The reporter's comments apply only to *system* preferences. These preferences are, by design, writable only by privileged users, but readable by "normal" users. The default location normally provides the desired behavior. It is possible to use a different directory for system preferences System prefs are normally rooted at /etc/.java/.systemPrefs in a "local install", or <java.home>/.systemPrefs in a "network install." This can be overridden by setting the System Property java.util.prefs.systemRoot, in which case system prefs are rooted at <java.util.prefs.systemRoot>/.systemPrefs. User prefs, on the other hand, are intended to be read and written by normal users. They are normally rooted at <user.home>/.java/.userPrefs. This can be overridden by setting the System Property java.util.prefs.userRoot, in which case user prefs are rooted at <java.util.prefs.userRoot>/.java/.userPrefs. If the user root directory does not exist, it is created the first time an application attempts to use user prefs. This generally works fine, as users can generally write in their own home directories. ###@###.### 2002-11-03
03-11-2002