| Paul Ilechko 2007-11-23, 1:24 pm |
| Sven Vermeulen wrote:
> Afaik, you also need to have the appserver run as the wasadmin user also (both dmgr, node agent and application server). <br />
> <br />
> Wkr,<br />
> Sven Vermeulen
No, this is not exactly true.
From Keys Botzum's WebSphere Hardening paper of Developerworks:
The WebSphere Application Server processes run on an operating system
and must therefore, run under some operating system identity. There are
three ways to run WebSphere Application Server with respect to operating
system identities:
* Run everything as root.
* Run everything as a single user identity, such as "was".
* Run the node agents as root and individual application servers
under their own identities.
IBM tests for and fully supports the first two approaches. The third
approach may seem tempting because you can then leverage operating
system permissions, but it isn't very effective in practice for the
following reasons:
*
It is difficult to configure and there are no documented
procedures. Many WebSphere Application Server processes need read access
to numerous files and write access to the log and transaction directories.
*
By running the node agent as root, you effectively give the
WebSphere Application Server administrator and any applications running
in WebSphere Application Server root authority.
*
The primary value of this approach is to control file system
access by applications. You can achieve this using Java 2 permissions.
*
This approach creates the false impression that applications are
isolated from each other. They are not. The WebSphere Application Server
internal security model is based on J2EE and Java 2 security and is
unaffected by operating system permissions. Thus, if you choose this
approach to protect yourself from "rogue" applications, your approach is
misguided.
The first approach is obviously undesirable because, as a general best
practice, it is best to avoid running any process as root if it can be
avoided. This leaves the second approach, which is fully supported and
provides application isolation (should that be desirable) when used in
conjunction with Java 2 security. Therefore, we recommend that approach.
|