commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Palmreuther (JIRA)" <>
Subject [jira] [Commented] (DAEMON-250) Dropping privileges "too late"
Date Thu, 31 May 2012 21:32:24 GMT


Peter Palmreuther commented on DAEMON-250:

Just to make this clear: *I* don't depend on users home dir. It's Java Runtime itself (java.util.prefs
to be precisely).

As I'm running Tomcat 7 on FreeBSD and it's start script does not offer to modify environment
using "export HOME=...".
I tried to add "-Djava.util.prefs.userRoot=/home/www" to parameter list, and it seemed to
have worked out this issue.
I don't see any exception in log files and my simple test class also didn't report any error.

Maybe this is something for FAQ / "Runtime problems", as it is *not* specific to _Tomcat_
or _FreeBSD_, but something pretty general. Any daemon that changes user and - for whatever
reason - makes use of "java.util.prefs.*" is about to have this problem. IMHO it's a (more
or less reasonable) limitation jsvc introduces to a standard JVM (and I'm using OpenJDK, so
it's not solely an Oracle-JVM related problem).

So ... Somehow sorry this cannot be fixed, albeit I admit this is for comprehensible reasons.
> Dropping privileges "too late"
> ------------------------------
>                 Key: DAEMON-250
>                 URL:
>             Project: Commons Daemon
>          Issue Type: Bug
>          Components: Jsvc
>    Affects Versions: 1.0.10
>         Environment: FreeBSD 8.3-RELEASE, OpenJDK 1.6.0_30-b24
>            Reporter: Peter Palmreuther
> When using "{{-user}}" argument for "{{jsvc}}" controlled (child) process runs as given
user. Alas the privileges dropping was done after several critical initializations already
have been done.
> Consider "{{-user www}}", while process started as "{{root}}" and this code:
> {quote}
>                 Preferences userRoot = null;
>                 try \{
>                         userRoot = Preferences.userRoot();
>                 \} catch (Exception e) \{
>                         e.printStackTrace();
>                 \} finally \{
>                         System.out.println("Prefs userRoot: " + ((null != userRoot)?userRoot.toString():"null"));
>                 \}
> {quote}
> Output (stderr) is:
> {quote}
> 03.05.2012 11:00:31 java.util.prefs.FileSystemPreferences$2 run
> WARNUNG: Couldn't create user preferences directory. User preferences are unusable.
> 03.05.2012 11:00:31 java.util.prefs.FileSystemPreferences$2 run
> WARNUNG: Permission denied
> Exception in thread "Thread-2" java.lang.SecurityException: Could not lock User prefs.
Lock file access denied.
> 	at java.util.prefs.FileSystemPreferences.checkLockFile0ErrorCode(
> 	at java.util.prefs.FileSystemPreferences.lockFile(
> 	at java.util.prefs.FileSystemPreferences.sync(
> 	at java.util.prefs.FileSystemPreferences.flush(
> 	at java.util.prefs.FileSystemPreferences.syncWorld(
> 	at java.util.prefs.FileSystemPreferences.access$1200(
> 	at java.util.prefs.FileSystemPreferences$5$
> {quote}
> {{ktrace}}-ing the example clearly shows the process is trying to access {{/root/.java/.userPrefs}}
(and below), although according to {{www}} being the targeted runtime user this should be
> I wouldn't mind, if this wouldn't render usage of {{java.util.prefs.*}} unusable. I'm
running a Tomcat with Nexus inside and the latter obviously tries to store preferences "the
java way". This seems to be pretty impossible when Tomcat is started using {{jsvc}} (as it
is per default in FreeBSD 8.3-RELEASE for Tomcat 7).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message