-
Bug
-
Resolution: Fixed
-
P4
-
17, 18
-
b12
-
generic
-
generic
A DESCRIPTION OF THE PROBLEM :
In some environments like a systemd service with DynamicUser=true, or in Docker, the NSS database isn't updated with useful information. In systemd querying the home directory returns "/" which is useless and in the past I've seen Docker environments return null, causing HotSpot to set user.home to "?". This can lead to very odd issues with directories name ? turning up all over the place as usually this value is passed straight to Path or File.
Some time ago I filed a bug against systemd asking them to put a more useful answer in NSS:
https://github.com/systemd/systemd/issues/19537
Unfortunately the maintainer doesn't want to fix this. His view is that everything on UNIX _except_ Java uses $HOME and that it's Java that needs to be fixed, as then a systemd unit can set HOME to something "meaningful" e.g. the state directory.
In the past, using $HOME for user.home has been deprioritized as being a potentially backwards incompatible change, presumably for weird UNIX environments where $HOME doesn't match the NSSDB even though $HOME is initialized from that db. So in this bug I propose a change that shouldn't have any compatibility issues - when NSS returns either "/" or NULL, fall back to reading $HOME and/or $STATE_DIRECTORY instead. Neither / nor ? are valid home directories on UNIX systems, thus presenting these values to an app is always wrong and can only break things.
This isn't a theoretical concern by the way. I'm currently dealing with some breakage of a Java app that runs in a systemd service because it tries to write to the root directory.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run this command on a Linux system with systemd and Java installed:
systemd-run -p DynamicUser=1 -p StateDirectory=xyz -p Environment=HOME=/var/lib/xyz -p WorkingDirectory=/var/lib/xyz -t /usr/bin/java -XshowSettings:properties --version | grep user.home
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
It points to a writable directory.
ACTUAL -
user.home is set to /
CUSTOMER SUBMITTED WORKAROUND :
A mix of setting system properties by hand, changing your own code, etc, but user.home is used all over the place including in libraries so this gets painful fast.
In some environments like a systemd service with DynamicUser=true, or in Docker, the NSS database isn't updated with useful information. In systemd querying the home directory returns "/" which is useless and in the past I've seen Docker environments return null, causing HotSpot to set user.home to "?". This can lead to very odd issues with directories name ? turning up all over the place as usually this value is passed straight to Path or File.
Some time ago I filed a bug against systemd asking them to put a more useful answer in NSS:
https://github.com/systemd/systemd/issues/19537
Unfortunately the maintainer doesn't want to fix this. His view is that everything on UNIX _except_ Java uses $HOME and that it's Java that needs to be fixed, as then a systemd unit can set HOME to something "meaningful" e.g. the state directory.
In the past, using $HOME for user.home has been deprioritized as being a potentially backwards incompatible change, presumably for weird UNIX environments where $HOME doesn't match the NSSDB even though $HOME is initialized from that db. So in this bug I propose a change that shouldn't have any compatibility issues - when NSS returns either "/" or NULL, fall back to reading $HOME and/or $STATE_DIRECTORY instead. Neither / nor ? are valid home directories on UNIX systems, thus presenting these values to an app is always wrong and can only break things.
This isn't a theoretical concern by the way. I'm currently dealing with some breakage of a Java app that runs in a systemd service because it tries to write to the root directory.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run this command on a Linux system with systemd and Java installed:
systemd-run -p DynamicUser=1 -p StateDirectory=xyz -p Environment=HOME=/var/lib/xyz -p WorkingDirectory=/var/lib/xyz -t /usr/bin/java -XshowSettings:properties --version | grep user.home
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
It points to a writable directory.
ACTUAL -
user.home is set to /
CUSTOMER SUBMITTED WORKAROUND :
A mix of setting system properties by hand, changing your own code, etc, but user.home is used all over the place including in libraries so this gets painful fast.
- csr for
-
JDK-8282102 If the users home directory is invalid, system property user.home is set to $HOME
- Closed
- relates to
-
JDK-7069190 user.home property should be configurable via the HOME variable
- Open