FileNet P8 Platform, Version 5.2.1            

File storage area security

Configuring file storage area security ensures that content files are safe from unauthorized usage.

Content Platform Engine operating system account

The Content Platform Engine operating system user (cpe_os_user) who logs on to the Content Platform Engine server and starts the local application server process is the account that must be used to secure the folders and files in a file storage area. From a practical standpoint, the account that is used to install the application server should be the same account that is used to start the application server process. As an administrator, you will always log on using the same operating system account to secure the folders and files in the file system that Content Platform Engine will use for a file storage area.

Optionally, you can use an operating system group account. All cpe_os_user accounts would be members of the group account. If you do not set up such a group, then that single user account cpe_os_user must be used to log on to each Content Platform Engine and file storage server instance.

  • For Windows-based Content Platform Engine and file storage areas, these operating system login accounts must reside in the same Windows domain or in trusted Windows domains.
  • For Content Platform Engine and file storage areas based in AIX®, HPUX, HPUXi, Linux, Linux on System z®, or Solaris, security is configured using NFS, the protocol suite developed by Sun Microsystems that allows different makes of computers running different operating systems to share files and disk storage. Configuring NFS security should be done by experienced network administrators. Consult your operating system documentation for details.
  • For a mixed environment of non-Windows and Windows, you will need an NFS Gateway product in order to provide interoperability between Windows-based and non-Windows-based clients.

    Important: When we speak of Content Platform Engine running under an operating system user account, we are referring to a specific instance of the JVM that is executing as a process on the host operating system. This particular JVM is hosting the application server that starts Content Platform Engine. The JVM executes with a set of credentials associated with a specific account known to the operating system on which the process is started. This account might or might not be defined as a user or group in the directory service that Content Platform Engine uses to authenticate users. It is not relevant whether or not Content Platform Engine knows about the account. What is relevant is that the operating system must know about it.
Shared root directory - Windows and AIX, HPUX, HPUXi, Linux, Linux on System z, or Solaris

A Content Platform Engine file storage area is always created under a shared root directory that has been created by the operating system user account, cpe_os_user. The cpe_os_user is responsible for securing the root directory in a way that grants full control access to the Content Platform Engine server (represented either by the cpe_os_user or group account) and preventing all other users from obtaining unauthorized access to files in the area.

The Create a Storage Area Wizard creates the storage area folder structures below the root directory, but does not directly set permissions on any of these folders. Instead, the folders are secured via inherited security. The inheritance scheme differs between Windows and AIX, HPUX, HPUXi, Linux, Linux on System z, or Solaris and is discussed in detail below. Note that when Content Platform Engine creates content element files within a storage area, it does not directly set permissions on the files; it always allows permissions to be inherited.

Inherited Security - Windows file system

Under Windows, file and folder permissions can be inherited via true inheritance. Folders and files can receive inherited permissions from their parent folder, without an application setting permissions on the newly created file or folder. The Content Platform Engine file security scheme under Windows requires the system administrator (who is logged on as cpe_os_user) to create the root directory in a way that provides proper inheritance and provides proper access control.

Secure the root directory of a file storage area as follows:

  • Remove unwanted inherited or inheritable permissions. This can also include preventing the root directory from inheriting permissions from its parent directory, since the parent will normally grant Read access to general groups like 'users'. Be careful not to accept the default security setting when creating a root directory, since the default will normally grant Read access to a broad set of users.
  • Grant the cpe_os_user full control access to the root directory. Make this inheritable by all folders and files created under the root.
  • As explained above, you can optionally grant full control access to the root directory to an operating system group account that the cpe_os_user belongs to. This must also be made inheritable by all folders and files. If you use a group account, it is not necessary to grant access to the individual user accounts.
  • If there is an administrative user or group that will need access to the files of the store, then grant Full Control access to the root folder to these accounts and make the permissions inheritable by all folders and files.
Sharing the root folder - Windows

Once it is secured, you must share the root folder so it can be accessed across the network. Permissions on a share cannot define access that is any less restrictive than the permissions of the folder that is shared. The recommended scheme is to grant full control access on the share to the same set of users and groups that have been granted full control access on the shared folder.

Important: Do not confuse security on the share with security on the shared folder. These are two different Windows security features. Consult Windows operating system online help documentation for definitions and procedures.
Inherited Security - AIX, HPUX, HPUXi, Linux, Linux on System z, and Solaris file systems

Under AIX, HPUX, HPUXi, Linux, Linux on System z, or Solaris, file and folder permissions are inherited via the file creation mask (called the umask) of the user that creates the file or folder. Files and folders do not inherit the access rights of the parent folder. The Content Platform Engine file security scheme under AIX, HPUX, HPUXi, Linux, Linux on System z, or Solaris is to require the system administrator to properly configure the creation mask of the Content Platform Engine operating system account (cpe_os_user) to grant the proper permissions on newly created files and folders. The root folder must be created with the same permissions as those granted by the cpe_os_user creation mask, which should grant the following permissions:

  • USER: Grant the cpe_os_user account read, write, and execute permissions.
  • GROUP: Grant the Content Platform Engine operating system group account read, write, and execute permission. Note that this will apply to either a private group (same Id as the user), or a specific operating system group account, depending on how cpe_os_user is configured. (Use of a non-private group account to control security is optional.)
  • OTHERS: Do not grant access. Be careful not to allow read access to Others.

Creation mask example:

umask u=rwx,g=rwx,o=

or

umask 0007
NFS Sharing

The root folder must be exported via NFS on the server side (meaning the computer that hosts the file system) and mounted (via NFS) on the client side. Once the root folder has been properly shared via NFS, security is enforced via the user and group identifiers of the client (as if the client logged on locally to the server computer). The client in this case is the Content Platform Engine server running on a remote computer.

Make sure you prevent non-local root access to a folder that has been exported via NFS, as allowing non-local root access has serious implications for security. For example, in Linux the no_root_squash option must not be included in the export options.



Last updated: March 2016
p8psa028.htm

© Copyright IBM Corporation 2016.