Page tree
Skip to end of metadata
Go to start of metadata

Introduction


This page shows you how to get FusionReactor up and running in environments where your application server is running as a different user than FusionReactor's FRAM service. The procedure is different depending on your operating system, so we've split it into sections.

What does secured mean?


In order to help secure their production operating systems, many people choose to run their application server not as root (or Local System on windows), but as a normal user, "locking down" the application.  

This is done to limit the effects of an attacker using malicious exploit to gain access to the server.  An attacker who exploits a weakness in a running server usually attempts to have that server run his arbitrary code, essentially gaining access to the system.  By running the server under a normal user account, rather than root (or Local System), the attacker can only gain the privileges associated with the normal user, rather than those of the superuser.

It is considered good practice to separate the privileges of servers and daemons by running them as normal users in this way, thereby granting only the minimum privilege needed to operate correctly.

How does this affect FusionReactor?


While we encourage users to lock down their application systems, this causes two issues for FusionReactor.

  1. FusionReactor's Administration Manager (FRAM, usually on port 8087) requires write access to parts of the application server in order to add itself as a monitoring element.
  2. Each FusionReactor instance in an installation requires read/write access to the FusionReactor installation folder, in order to - for example - serve HTML objects, write persistent configuration and so on.

In a secure environment, FusionReactor may be running as one user, while the application runs as another.  This means that - for instance - FusionReactor may not able to modify read or write to files that it uses.

Solution


The solution is to create a common group, add both users to this group, and use File Access Control Lists (FACLs) to grant access to both FusionReactor and the application server to this group. There is relatively low risk in this solution, as it does not involve granting "world" (Everybody) permissions. Only the two users will be able to access each others' resources.

We have developed the following procedures for Linux, Solaris and Windows. The procedure does the following:

  1. Create a new group "fusion" to be a common group of both the FusionReactor runtime user ("nobody" on Linux) and the application server user ("myapplicationserver").
  2. Add both users to this group.
  3. Sets file ACLs and Default ACLs (so new files and directories inherit the ACL rights) on the application server and FusionReactor.

The procedure uses FusionReactor running as "nobody" on Linux. If you have multiple application servers, their users must also be added to the common group, and their Access Control Entries (ACE) and default ACEs must also be set.

If you later add new users and application servers, simply add their users to the common group, and add Access Control Entries as detailed in each procedure.

Linux


Requires kernel 2.6 or later, with a file system supporting ACLs (ReiserFS, ext2, ext3, JFS, XFS), mounted with ACL support (default).

On Linux, FusionReactor is typically installed as nobody. In our test environment myapplicationserver is running with the appuser user.  If your users differ, substitute them in the commands below.  The following commands should be run as root with FusionReactor (framd) and your application server stopped.

If your nobody user has a shell which prevents login (e.g. /sbin/nologin), you may need first apply technote FRS-284 to resolve this issue.

  1. Add the common group fusion

    groupadd fusion
    
  2. Add FusionReactor's runtime user, and myapplicationserver's (substitute your application server's) runtime user to the common group

    gpasswd fusion --members nobody,appuser
    
  3. Add file Access Control Entries to both FusionReactor and myapplicationserver (substitute your application server) directories

    setfacl -R -m g:fusion:rwx /opt/myapplicationserver /opt/fusionreactor
    
  4. Add default file Access Control Entries to the same directories.  This allows either system to create new directories and have the entries propagate.

    setfacl -R -m d:g:fusion:rwx /opt/myapplicationserver /opt/fusionreactor
    

Windows


Requires Windows Server 2003 Service Pack 2, Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows Server 2012 R2.

On Windows, FusionReactor is installed as the Local System user. Running as another user is currently unsupported. In our test environment, we are running myapplicationserver as the user appuser. The following commands should be run in a cmd window as a user who has Administrator rights to the system. If you cannot log in as an Administrator, a command window may be opened from a normal cmd session using the following command:

runas /user:Administrator cmd

FusionReactor and your application server should be stopped.

  1. Add the group fusion

    net localgroup /add fusion
    
  2. Add myapplicationserver's (substitute your application server's) runtime user to the group

    net localgroup fusion /add appuser
    
  3. Add a default file Access Control Entry to the myapplicationserver (substitute your application server) directory (this will propagate down automatically)

    icacls c:\myapplicationserver /grant fusion:(OI)(CI)F
    
  4. Add a default file Access Control Entry to the FusionReactor directory (this will propagate down automatically)

    icacls c:\FusionReactor /grant fusion:(OI)(CI)F
    

 

  • No labels