commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Kolinko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DAEMON-250) Dropping privileges "too late"
Date Thu, 31 May 2012 11:16:24 GMT

    [ 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

        

Mime
View raw message