IBM MQ file system permissions applied to /var/mqm

The following information describes the security applied to the files and directories under /var/mqm/ and why the file-system permissions are set as they are. In order to ensure the correct operation of IBM MQ you should not alter the file system permissions as set by IBM MQ


crtmqdir command

From IBM MQ Version 9.0.3, if your enterprise has changed any of the /var/mqm file permissions, for whatever reason, we can update the permissions, or add directories, by using the crtmqdir command


IBM MQ file system Security on UNIX, Linux, and IBM i

The files under the IBM MQ data directory (/var/mqm) are used to store:

  • IBM MQ configuration data
  • Application data (IBM MQ objects and the data contained within IBM MQ messages)
  • Run-time control information
  • Monitor information (messages and FFST files)

Access to this data is controlled using file system permissions with some of the data being accessible to all users while other data is restricted only to members of the IBM MQ Administrator group 'mqm' (or QMQM on IBM i).

Access is granted in the following three categories:


mqm group only

The files and directories in this category are only accessible to IBM MQ Administrators (members of the 'mqm' group) and the IBM MQ queue manager processes.

The file permissions for these files and directories are: 
    -rwxrwx---    mqm:mqm      (UNIX and Linux)
    -rwxrwx---    QMQMADM:QMQM (IBM i)
An example of the files and directories in this category is: 
    /var/mqm/qmgrs/QMGR/qm.ini
    /var/mqm/qmgrs/QMGR/channel/
    /var/mqm/qmgrs/QMGR/channel/SYSTEM!DEF!SCRVONN
    /var/mqm/qmgrs/QMGR/queues/
    /var/mqm/qmgrs/QMGR/queues/SYSTEM!DEFAULT!LOCAL!QUEUES/
    /var/mqm/qmgrs/QMGR/errors/
    /var/mqm/qmgrs/QMGR/errors/AMQERR01.LOG
    /var/mqm/qmgrs/QMGR/ssl/
    /var/mqm/qmgrs/QMGR/@qmgr/
    /var/mqm/qmgrs/QMGR/@qmpersist/
    ...


All users read access - mqm group members read and write access

The files and directories in this category can be read by all users, but only members of the 'mqm' group can modify these files and manipulate these directories.

The file permissions for these files and directories are: 
    -rwxrwxr-x    mqm:mqm      (UNIX and Linux)
    -rwxrwxr-x    QMQMADM:QMQM (IBM i)
An example of the files and directories in this category is: 
/var/mqm/mqs.ini
/var/mqm/exits/
/var/mqm/qmgrs/
/var/mqm/qmgrs/QMGR/
/var/mqm/qmgrs/QMGR/@app/
/var/mqm/qmgrs/QMGR/@ipcc/
IBM MQ Version 8.0: 
/var/mqm/sockets/@SYSTEM
/var/mqm/sockets/QMGR/@app/hostname
/var/mqm/sockets/QMGR/@ipcc/hostname


All users read and write access

Files that have read and write access for all users

IBM MQ has no regular files that have world writable file permissions (777). However there are a number of special files that appear as having world writable file permissions.

These special files provide no security exposure. Although the permissions are shown as 777, they are not regular files and we cannot write directly to them.

These special files are:

    Symbolic links
    Symbolic links are identified by the 'l' character at the start of their permissions. The permissions on the symbolic link have no effect on who is able to access the target file, as access to the command is controlled by the permissions on the target of the symbolic link.
    On most UNIX and Linux systems it is not possible to change the permissions on symbolic links, so they always appear as lrwxrwxrwx.

    Socket files
    Socket files are special files created by the operating system, as a result of a process creating a UNIX domain socket. These files can be identified by the 's' at the start of the file permissions, that is srwxrwxrwx.
    The permissions on the file do not grant access to the file itself, but define who can connect to the UNIX domain socket.
    IBM MQ uses a number of these socket files and the permissions are always set according to who is allowed to communicate with the socket.
    The following directories contain socket files that have read/write permissions for all users (srwxrwxrwx).
    IBM MQ Version 8.0: 
    /var/mqm/sockets/QMGR/zsocketEC/hostname/Zsocket_*
    Socket files used by applications that connect to IBM MQ using isolated bindings. 
    /var/mqm/sockets/QMGR/@ipcc/ssem/hostname/*

Directories that have read and write access for all users

There are times when IBM MQ applications need to create files under the IBM MQ data directory. To ensure that applications are able to create files when they are required, a number of directories are granted world write access, which means that any user on the system can create files within that directory.

With the exception of the errors logs files, that can be written to by any member of the 'mqm' group, all files created in these directories are created with restricted permissions that allows only the file creator write access. This allows the system administrator to track the user ID of all data written to files in these directories.

    /var/mqm/errors/
    This directory contains the system error log files and FFST files. The permission of this directory is 'drwxrwsrwt' meaning that all users on the system can create files in this directory.
    The SetGroupId bit 's' indicates that all files created in this directory have the group ownership of 'mqm'.
    The 't' sticky bit is not set by default on this directory, but an IBM MQ administrator can set this explicitly, to allow users to delete only the files that they create.Note: This feature is not available on IBM i.

      AMQERR0*.LOG
      These error log files can only be written to directly by members of the group but any user can read the messages written to these files (permission: -rw-rw-r--).

      AMQnnnnn.*.FDC
      These files contain FFST information written when an error occurs in the queue manager or in an application written by a user. These files are created with the permissions -rw-r-----.

    /var/mqm/trace/
    Trace files are written to this directory when IBM MQ trace is enabled. IBM MQ trace is written by all process associated with a queue manager for which trace is enabled.
    The permissions of this directory are 'drwxrwsrwt' meaning that all users on the system can create files in this directory.
    The SetGroupId bit 's' indicates that all files created in this directory have the group ownership of 'mqm'.
    The 't' sticky bit is not set by default on this directory, but an IBM MQ administrator can set this explicitly, to allow users to delete only the files that they create.Note: This feature is not available on IBM i.

      AMQnnnnn.*.TRC
      These files contain the trace data written by each process which is tracing and are created with permissions -rw-r-----
      The permissions on this directory are drwxrwsrwt and the permissions of the socket files created in this directory are srwx------.

      IBM MQ Version 8.0:
      /var/mqm/sockets/QMGR/zsocketapp/hostname/
      This directory is used by applications that connect to the IBM MQ queue manager using isolated bindings. During connect processing a socket file is created by the connecting application in this directory. The socket file is removed after the connection is made to the queue manager.
      The permissions on this directory are drwxrwsrwt and the permissions of the socket files created in this directory are srwx------.
      The SetGroupId bit 's' on this directory ensures that all files created in this directory have the group ownership of 'mqm'.
      On all platforms except IBM i, this directories also has the 't' sticky bit set which prevents a user from deleting any files except the ones for which they are the owner. This prevents an unauthorized user from deleting files that they do not own. 
      /var/mqm/sockets/QMGR/@ipcc/ssem/hostname/
/var/mqm/sockets/QMGR/@app/ssem/hostname/
      For processes that connect to IBM MQ using shared bindings then UNIX domain sockets might be used to synchronize between the application and the queue manager. When UNIX domain sockets are being used then the associated socket file is created in these directories.
      The permissions on these directories are drwxrwsrwt and the permissions of the socket files created in these directories are srwxrwxrwx.
      The SetGroupId bit 's' on these directories ensures that all files created in these directories have the group ownership of 'mqm'.
      On all platforms except IBM i, these directories also have the 't' sticky bit set which prevents a user from deleting any files except the ones for which they are the owner. This prevents an unauthorized user from deleting files that they do not own.

Use of System V IPC resources by IBM MQ

IBM MQ uses System V shared memory and semaphores for inter-process communication. These resources are grouped according to how they are used with each group having appropriate ownership and access permissions.

To verify which of the System V IPC resources on a system belong to IBM MQ we can:

  • Check the ownership.

    The owning user of IBM MQ System V IPC resources is always the 'mqm' user on UNIX platforms and Linux. On IBM i the owning user is 'QMQM'.

  • IBM MQ Version 8.0 and later, use the amqspdbg utility.

    The amqspdbg utility which is shipped with IBM MQ can be used to display the shared memory and semaphore id's for a given queue manager.

    You must issue the command once for the 'system' group of System V resources created by IBM MQ 
    # amqspbg -z -I
    and then four times for each queue manager on the system to get the complete list of System V resources used by IBM MQ. Assume a queue manager name of QMGR1 in the following examples:. 
    # amqspdbg -i QMGR1 -I
# amqspdbg -q QMGR1 -I
# amqspdbg -p QMGR1 -I
# amqspdbg -a QMGR1 -I

The access permissions on the System V resources created by IBM MQ are set to grant only the correct level of access to the permitted users. A number of the System V IPC resources created by IBM MQ are accessible to all users on the machine and have permissions of -rw-rw-rw-.

The -g ApplicationGroup parameter on the crtmqm command can be used to restrict access to a queue manager to membership of a specific operating system group. The use of this restricted group functionality restricts the permissions granted on the System V IPC resources further.