[
https://issues.apache.org/jira/browse/DAEMON-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13286975#comment-13286975
]
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: https://issues.apache.org/jira/browse/DAEMON-250
> 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: java.io.IOException: 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(FileSystemPreferences.java:936)
> at
> java.util.prefs.FileSystemPreferences.lockFile(FileSystemPreferences.java:925)
> at
> java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:731)
> at
> java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:824)
> at
> java.util.prefs.FileSystemPreferences.syncWorld(FileSystemPreferences.java:468)
> at
> java.util.prefs.FileSystemPreferences.access$1200(FileSystemPreferences.java:50)
> at
> java.util.prefs.FileSystemPreferences$5$1.run(FileSystemPreferences.java:446)
> {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 {{~www/.java/.userPrefs}}.
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
