IBM Connections – root vs. non-root installation

IBM Connections – root vs. non-root installation

Hi all,

this time I want to provide some arguments, why you should install IBM Connections (or any other WebSphere related software where non-root installations are supported) using a non-root user.

Last week I did a health check on an IBM Connections environment that was installed by the customer itself. It is a production environment with about 5000 registered users that is available from Internet.

The first thing that bumped into my eyes was the fact that this environment is operated by „root“. In my opinion this is not suitable for enterprise environments and represents a security risk.

With a non-root installation the IBM Connections administrator does not have full execution rights on the system. This might prevent deletion of system components and further restricts access when malicious code is executed. This does not mean that you do not have a problem when malicious code is executed but the damage might be limited.

I was involved in WebSphere Portal development projects, where Java Code executed system calls on operating system level. Running such a WebSphere environment as root can cause problems if the developer does not carefully takes care of what command is executed.

From the installation point of view, both methods do not differ that much. For a non-root installation you should create an installation directory and change the appropriate permissions prior starting the installation. You need to change a flag for IM to realize that you`re not using a root user.

 

For sure there are software parts or situations, where the root usage makes sense. Let`s have a look at those.

Special rules for HTTP Server

When you start the HTTP Server as root, a parent process gets started. This is done in order to be able to bind to ports < 1024 (e.g. 80 / 443). Anyway the child processes / threads are started as non-root user – e.g. „ihsuser“ – a user with lower system rights. The child threads handle the requests so that this constellation is like a non-root usage.

 

Limitations – where I would not recommend using a non-root user

DB2 – here I would rather install as root-user because non-root db2 installations have a limitation to only allow one single instance (I prefer having multiple instances for IBM Connections). Furthermore you cannot choose the installation directory – DB2 will be installed in the non-root home directory, which might not fit your requirements.  You can read more about this here

Forms Experience Builder – this is a requirement to install the components as root – after installation you can change the user (read here)

WCT – need to be executed as root, because it creates a system user (e.g. ihsuser). Anyway you can also create the user by hand. But this makes the process a bit more complicated.

My experiences reg. root – non-root usage

From my experience it does not make a big difference in handling a root or a non-root installation. Using a non-root user already preserved me from deleting operating system files and components 😉

In general you should prepare start / stop scripts for the application that checks, which user is currently logged in (so that you do not by default start the application as root).

It is standard in companies with a well organized and professional IT to only allow non-root installations.  I can only encourage everyone, who wants to setup an enterprise architecture to stick to the rule “USE NON-ROOT USERS TO INSTALL AND OPERATE WEBSPHERE COMPONENTS WHEREVER POSSIBLE”

By the way you can also install the software as root and then completely “chown” the installation. That`s valid but the problem here is that updates have to be installed as root… So in restrictive environments where the Linux administrators take away root-access after installation you`ll run into trouble and unnecessary discussions.

You might talk to the Linux administrator to make use of the sudoers file, so that your non-root user can execute specific commands that need to be executed with root permissions (e.g. start / stop HTTP Server or mount a NFS share)

I hope this helps a bit in deciding how to install IBM Connections. Your customer always expects the most secure and available environment! This is the first step in building up such an environment.

 

Feel free to comment on this and send me any other restrictions or ideas regarding this important topic.

 

Leave a Reply

Your email address will not be published. Required fields are marked *