Bug 110561

Summary: Production servers startup as 'root' instead of unprivileged user 'servlet'
Product: [Retired] Red Hat Web Application Framework Reporter: Daniel Berrangé <berrange>
Component: otherAssignee: Dennis Gregorovic <dgregor>
Status: CLOSED RAWHIDE QA Contact: Jon Orris <jorris>
Severity: medium Docs Contact:
Priority: medium    
Version: nightlyKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-12-04 22:32:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 109665    

Description Daniel Berrangé 2003-11-21 10:01:56 UTC 
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:
ALWAYS

Steps to Reproduce:
1. Login to a server as root
2. Run 'ccm start'
3.
  
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 Berrangé 2003-11-21 10:08:33 UTC 
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
        user.
                                                           [FAILED]
[root@camden root]#
Comment 2 Dennis Gregorovic 2003-11-21 18:20:28 UTC 
@38218
Comment 3 Jon Orris 2003-12-01 16:02:46 UTC 
Marking QA Ready.
Dan, can you comment on whether the solution is OK, as you opened the
ticket?
Comment 4 Daniel Berrangé 2003-12-01 16:10:11 UTC 
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 18:31:01 UTC 
changes checked in @38383