[jira] [Created] (DAEMON-250) Dropping privileges "too late"

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Created] (DAEMON-250) Dropping privileges "too late"

Gary D. Gregory (Jira)
Peter Palmreuther created DAEMON-250:
----------------------------------------

             Summary: 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

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (DAEMON-250) Dropping privileges "too late"

Gary D. Gregory (Jira)

    [ 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

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (DAEMON-250) Dropping privileges "too late"

Gary D. Gregory (Jira)
In reply to this post by Gary D. Gregory (Jira)

    [ https://issues.apache.org/jira/browse/DAEMON-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13286480#comment-13286480 ]

Konstantin Kolinko commented on DAEMON-250:
-------------------------------------------

To expand the previous comment.

One of purposes of jsvc is to allow Apache Tomcat to bind to port 80. To allow that the init() method of the server must be called with root privileges so that it can open ServerSocket on that port. After that the user is switched and start() is performed as common user.

Thus I agree that this cannot be fixed.
               

> 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

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (DAEMON-250) Dropping privileges "too late"

Gary D. Gregory (Jira)
In reply to this post by Gary D. Gregory (Jira)

    [ 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

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Closed] (DAEMON-250) Dropping privileges "too late"

Gary D. Gregory (Jira)
In reply to this post by Gary D. Gregory (Jira)

     [ https://issues.apache.org/jira/browse/DAEMON-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palmreuther closed DAEMON-250.
------------------------------------

    Resolution: Won't Fix

No chance to fix this, conflicting requirements (early privileged port binding vs. non-privileged file access based on user environment values => environment changing setuid() cannot be done before Java is initialized).

Workaround: make use of '-Djava.util.prefs.userRoot=/home/www'
               

> 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