[
https://issues.apache.org/jira/browse/DAEMON-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267693#comment-13267693
]
Mladen Turk commented on DAEMON-250:
------------------------------------
You should not depend on users home dir because the entire purpose of jsvc is to
switch the user, so the home changes.
We must switch user after the init is done, otherwise there's no point of having
the daemon at the first place.
You can try with setting
export HOME=/home/www (or whatever)
./jsvc ...
(presuming that Java's Preferences use user.home for that)
However those files will probably (if written) be owned by root until the user
is changed.
> 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
