Bug 110561 - Production servers startup as 'root' instead of unprivileged user 'servlet'
Production servers startup as 'root' instead of unprivileged user 'servlet'
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dennis Gregorovic
Jon Orris
: Security
Depends On:
Blocks: 109665
  Show dependency treegraph
Reported: 2003-11-21 05:01 EST by Daniel Berrange
Modified: 2007-04-18 12:59 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-12-04 17:32:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2003-11-21 05:01:56 EST
Description of problem:
The original production start / stop scripts always 'su -' to an
unprivileged user (defaulting to 'servlet'). This is an absolutely
critical security precaution taken by *all* UNIX server software. At
most, a server will start off as root & then drop its privileges
before accepting any internet connections.

There is no reason to even start an application server as root, since
any serious deployment will have an apache (or equivalent) front end
on port 80, forwarding requests using mod_caucho/mod_jk.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Login to a server as root
2. Run 'ccm start'
Actual results:
The JVM is running as 'root'

Expected results:
The JVM is running as an unprivileged user 'servlet' (or equivalent
such as 'nobody').

Additional info:
Really well written software will *refuse* outright to run as 'root',
even if the user tries to tell it so. For example, if you set
'cache_effective_user' to 'root' in squid.conf it will exit, printing:

  "Don't run Squid as root, set 'cache_effective_user'!"

Our automated configuration/startup scripts should do likewise.
Comment 1 Daniel Berrange 2003-11-21 05:08:33 EST
People trust security of Apache much, much more than any Java app
server, & even that will refuse to run as 'root' :

[root@camden root]# grep '^User' /etc/httpd/conf/httpd.conf
User root
[root@camden root]# 
[root@camden root]# /etc/init.d/httpd start
Starting httpd: Error:  Apache has not been designed to serve pages while
        running as root.  There are known race conditions that
        will allow any local user to read any file on the system.
        If you still desire to serve pages as root then
        add -DBIG_SECURITY_HOLE to the EXTRA_CFLAGS line in your
        src/Configuration file and rebuild the server.  It is
        strongly suggested that you instead modify the User
        directive in your httpd.conf file to list a non-root
[root@camden root]# 
Comment 2 Dennis Gregorovic 2003-11-21 13:20:28 EST
Comment 3 Jon Orris 2003-12-01 11:02:46 EST
Marking QA Ready.
Dan, can you comment on whether the solution is OK, as you opened the
Comment 4 Daniel Berrange 2003-12-01 11:10:11 EST
It solves the original problem, yes, but there a some small
improvements that will make it more robust to error conditions:

 1. refuse point blank to run if servlet user is set to 'root'
 2. If the current user matches the desired user, then don't 'su' at
all - just run the startup.
 3. If the servlet user is specified & the user is not logged in as
root, then refuse to startup. As it stands it will silently startup as
the current user - this could lead to people mistakenly running a
production server as the wrong user. 
Comment 5 Dennis Gregorovic 2003-12-01 13:31:01 EST
changes checked in @38383

Note You need to log in before you can comment on or make changes to this bug.