commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Turk (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DAEMON-250) Dropping privileges "too late"
Date Thu, 03 May 2012 19:00:55 GMT

    [ 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

        

Mime
View raw message