The Security extension (SECURITY), along with the MIT-MAGIC-COOKIE-1 and MIT-KERBEROS-5 protocols, provides additional means for defining which clients are authorized to connect to the X server and what operations they can perform once connected. Use the new parameters in this section to specify the location of the files used with these mechanisms (security policy, X authority, access allowed, and access trusted files).

See Section 2.6 for details on defining and implementing an authentication scheme for the DECwindows X11 Display Server. For a brief description of the SECURITY extension, see Section 3.5.1.6.

DECW$SECURITY_POLICY

When using SECURITY, this parameter specifies the name of the security policy file. By default, no file is specified.

The following parameter specifies the security policy file SYS$MANAGER:DECW$SECURITY_POLICY.DAT:

Example

$ DECW$SECURITY_POLICY == "SYS$MANAGER:DECW$SECURITY_POLICY.DAT"

See Section 2.6.5.2 for a description of the security policy file.

DECW$SERVER_XAUTHORITY

This parameter specifies the name of the server X authority file. This file provides records used to authorize client connections to the server. By default, no file is specified. This allows access to the X server from the local SYSTEM account (via DECnet or the Local transport) without requiring additional authentication from the client.

Note that the settings in the X authority file specified by DECW$SERVER_XAUTHORITY apply to server connections made before a user logs into the DECwindows desktop. Once a user logs into the desktop, the user's X authority settings are applied.

If a file is specified, the values from this file are loaded into the server and can be used by all client connections. To allow a normal login process to occur, trusted access must be explicitly granted using the DECW$SERVER_ACCESS_TRUSTED.DAT file.

The following parameter specifies the X authority file SYS$MANAGER:DECW$XAUTH.DAT:

Example

$ DECW$SERVER_XAUTHORITY == "SYS$MANAGER:DECW$XAUTH.DAT"

See Section 1.2.2.1 for a description of the X authority file.

DECW$SERVER_ACCESS_TRUSTED

This parameter specifies the name of the trusted access file. This file lists those clients who maintain trusted access to the server. The default file is SYS$MANAGER:DECW$SERVER_ACCESS_TRUSTED.DAT.

Note that the settings in the trusted access file specified by DECW$SERVER_ACCESS_TRUSTED apply to server connections made before a user logs into the DECwindows desktop. Once a user logs into the desktop, the user's access settings are applied.

The following parameter changes the trusted access file specification:

Example

$ DECW$SERVER_ACCESS_TRUSTED == "SYS$MANAGER:DECW$SERVER1_ACCESS_TRUSTED.DAT"

DECW$SERVER_ACCESS_ALLOWED

This parameter specifies the name of the access allowed file. This file lists those clients who are granted automatic access to the server without requiring additional authentication. The default file is SYS$MANAGER:DECW$SERVER_ACCESS_ALLOWED.DAT.

Note that the settings in the allowed access file specified by DECW$SERVER_ACCESS_ALLOWED apply to server connections made before a user logs into the DECwindows desktop. Once a user logs into the desktop, the user's access settings are applied.

The following parameter changes the allowed access file specification:

Example

$ DECW$SERVER_ACCESS_ALLOWED == "SYS$MANAGER:DECW$SERVER1_ACCESS_ALLOWED.DAT"

2.1.5 Error Reporting

DECW$SERVER_AUDIT_LEVEL

This parameter controls whether normal client connect/disconnect messages are logged in the error log file for the server. Valid values for this parameter are:

• 0 (disabled)
• 1 (enabled)
• 2 (enabled with success messages)
• 4 (enabled with security logging)

The default value is 0.

The following parameter definition enables minimal audit logging:

Example

$ DECW$SERVER_AUDIT_LEVEL == "1"

2.2 Enhanced Support for Dynamically Loadable Extensions

Since some combinations of X server extensions present a function or resource conflict if enabled concurrently, two new parameters (DECW$SERVER_EXTENSIONS and DECW$SERVER_DISABLE_TEST) have been added to the server startup file. These parameters allows you to control which groups of extensions are loaded and enabled on one or more servers. Each dynamically loadable extension specified by these symbols is converted to a shareable image, which is run at server startup.

To load and enable a set of extensions, modify the parameter definitions in the DECW$PRIVATE_SERVER_SETUP.COM file, and restart the server. For example, to enable XIE and XINERAMA, add the following line to the file:

$ DECW$SERVER_EXTENSIONS == "XIE,XINERAMA"

See Section 2.1.1 for a detailed description of the valid values for these parameters. For the current list of unsupported combinations of X server extensions, see the hp DECwindows Motif for hp OpenVMS Alpha Release Notes.

2.3 Support for Multihead Systems Using XINERAMA

The XINERAMA extension enables you to connect multiple monitors to a single Alpha system running HP DECwindows Motif for HP OpenVMS Alpha Version 1.3 to create a unified virtual display. In contrast to the traditional way of configuring multiheaded Alpha systems, described in Managing DECwindows Motif for OpenVMS Systems, XINERAMA provides more control over the arrangement of the screens and desktop. Under a multiheaded display that uses XINERAMA, you can customize the number, order, and configuration of each screen in the display, and drag windows and text from screen to screen on the desktop.

The following sections describe how to configure a multiheaded Alpha system using XINERAMA.

2.3.1 Hardware and Configuration Requirements

XINERAMA is supported only in a homogeneous graphics environment. Each multiheaded configuration must consist of common video cards, bit depths, visual classes, screen resolutions, and monitors of a similar size.

See the hp DECwindows Motif for hp OpenVMS Alpha Software Product Description for a list of the currently supported video graphics cards; see Managing DECwindows Motif for OpenVMS Systems for a description of the logicals you can use to change the default values for these graphics settings.

The X server supports up to 16 monitors in a multiheaded configuration. Note that the actual number of monitors you can use may be further limited by the number of available option card slots.

2.3.2 Setting Up a Multiheaded Alpha System

Configuring a multiheaded system using XINERAMA involves the following steps:

1. Disable VGA Services
2. Install the Video Cards
3. Enable XINERAMA
4. Arrange and Configure the Monitors

The following sections describe this process.

Step 1: Disable VGA Services

Some video cards can dynamically disable or enable VGA services as necessary, but others require that you manually disable VGA via a jumper setting on the video card. Refer to the documentation for your video cards to determine if this change is required. If so, make this change prior to installing the cards in your Alpha system.

Step 2: Install the Video Cards

Shut down the OpenVMS Alpha system and install the video cards, as instructed by the hardware documentation.

Turn the power back on and reboot the operating system. During startup, the OpenVMS Alpha operating system will verify that the video cards were installed correctly.

Step 3: Enable XINERAMA

Although this extension is part of the X server, it is not enabled by default. To enable XINERAMA:

1. Edit the DECW$PRIVATE_SERVER_SETUP.COM file.
2. Search for and define the parameter DECW$SERVER_EXTENSIONS so that it includes a value of "XINERAMA." For example:

   $ DECW$SERVER_EXTENSIONS == "DEC-XTRAP,XINERAMA"

3. Save the file and restart the server.

Step 4: Arrange the Monitors

By default, the system uses the physical location of the video cards on the system bus to assign the device names (such as, GYA0, GYB0, etc.) and subsequently number the screens. For example in a four-monitor multihead configuration, if you have connected the cables to the video cards in the proper order and placed the monitors placed side-by-side, the screens could be numbered in either ascending (0, 1, 2, 3) or descending (3, 2, 1, 0) order.

If the screens are not in the desired order, you can do one of the following depending on your screen configuration:

• Physically move the monitors to the correct placement.
• Reconnect the cables in the correct order.
• Edit the DECW$PRIVATE_SERVER_SETUP.COM file and define the DECW$SERVER_SCREENS parameter so that it overrides the default screen order.

Once the screens are in the appropriate order, you can further customize the virtual display using the following edge attachment parameters in DECW$PRIVATE_SERVER_SETUP.COM:

• DECW$SERVER_EDGE_LEFT
• DECW$SERVER_EDGE_RIGHT
• DECW$SERVER_EDGE_TOP
• DECW$SERVER_EDGE_BOTTOM

These parameters, described in Section 2.1.2, control where each edge of the virtual display is attached.

When the setup process is complete, all the monitors should be active and organized in the proper arrangement. Once you restart DECwindows Motif, the login dialog box for the session is displayed at the center of the virtual display, and you should be able to open application windows and drag them from screen to screen.

2.4 Support for Euro Currency Symbol

Support for the euro symbol is enabled through a DECwindows Motif installation option. This option installs the appropriate fonts in the DECW$SYSCOMMON:[SYSFONT.DECW] subdirectory tree and adds references to the euro font directories to the search list defined by the DECW$FONT logical.

No further configuration is required. Note however, that if installed on an OpenVMS Alpha cluster system, you must restart DECwindows on all other systems in the cluster in order for them to recognize the symbol.

Support for the euro locale by the OpenVMS C Run-Time Library is not required for base DECwindows Motif euro support. However, if you want to run Motif applications in a euro locale, you must install Euro locale support, which is included in the OpenVMS Alpha Version 7.3--1 kit.

Once euro support is enabled on your system, you can display the euro sign with any ISO8859-1 bitmap font on your workstation, with no additional setup. DECwindows Motif applications that use standard ISO Latin-1 fonts to display text will automatically display the euro sign for character 0xA4. The character set portion of the XLFD name for these fonts is ISO8859-1.

To display the euro sign in a DECterm window, be sure the following two items are selected in the DECterm General Options dialog box:

• UPSS ISO Latin-1
• 8-Bit Multinational Characters

2.4.3 Using the Keyboard to Manually Enter the Euro Symbol

Compose+Space o x or Compose+Space O X

Compose+Space x o or Compose+Space X O

Compose+Space 0 x or Compose+Space 0 X

Compose+Space x 0 or Compose+Space X 0

To display and edit the euro symbol in the DECTPU DECwindows interface, specify the ISO Latin-1 character set as follows:

$ EDIT/TPU/INTERFACE=DECWINDOWS/CHARACTER_SET=ISO_LATIN1

2.5 Support for X Keyboard Keymap Files

The X Keyboard keymap files are the standard X Window System alternative to the proprietary keymaps currently provided with DECwindows Motif. They are intended to supplement, rather than replace, the DECwindows Motif keymap files, which will continue to be provided with the DECwindows Motif software.

You can compile X Keyboard layout files to create loadable keymaps using the X Keyboard Compiler utility (xkbcomp), as described in the following section, or the server will compile the files as needed.

Also, since the X Keyboard keymap format (.XKM) is the accepted, vendor-independent standard for loadable keyboards, you can choose to load .XKM files from other X11R6-based systems and X Window System software providers.

2.5.1 Creating a Modified Keymap File

To create a modified keymap file, do the following:

1. Edit the one or more component source files described in Section 1.2.3.1, and make the necessary changes. For example, to swap the left and right parenthesis for all US keymaps, edit SYS$COMMON:[SYS$KEYMAP.XKB.SYMBOLS.DIGITAL]US, as follows:

   . . . 19 key <AE09> { [ 9, parenleft ] }; 20 key <AE10> { [ 0, parenright ] }; . . .

2. Compile the component source files to create the modified keymap file. For example, to create a modified keymap file for DIGITAL_US_LK401, compile the sources as follows:

   $ xkbcomp -RDECW$SYSCOMMON:[SYS$KEYMAP.XKB] -xkm -m lk401 - _$ DECW$SYSCOMMON:[SYS$KEYMAP.XKB.KEYMAP.DIGITAL]us - _$ -o SYS$COMMON:[SYS$KEYMAP.XKB.COMPILED]digital_us_lk401.xkm

You can then load the modified, compiled keymap file as described in Section 2.5.2.

2.5.2 Loading a Compiled Keymap File

To load a compiled X Keyboard keymap file, do the following:

1. Edit the DECW$PRIVATE_SERVER_SETUP.COM file.
2. Define the value of the parameter DECW$SERVER_EXTENSIONS so that it enables the use of the X Keyboard (XKB) extension, similar to the following:

   $ DECW$SERVER_EXTENSIONS == "XKB,XINERAMA"

3. Define the value of the parameter DECW$SERVER_XKEYBOARD_LOAD_MAP to enable the use of X Keyboard keymaps:

   $ DECW$SERVER_XKEYBOARD_LOAD_MAP=="1"

4. Define the value of the DECW$SERVER_XKEYBOARD_COMPILED_DIR parameter to point to where the keymap files are located. This directory is also where the server places any keymap files that it compiles on demand.
5. Define the value of the DECW$SERVER_XKEYBOARD_MAP parameter to point to the default X Keyboard keymap to load at server startup.
6. Save the file and restart the server.

To enable the AccessX key features described in Section 1.2.1, do the following:

1. Edit the DECW$PRIVATE_SERVER_SETUP.COM file.
2. Search for and set the DECW$SERVER_ENABLE_ACCESSX parameter to a value of 1 (enabled).
3. Save the file, and restart the server.

You can then further configure the AccessX features using the accessx utility described in Section 1.2.1, or use the slow and sticky key functions, as follows:

To...	Perform This Action...
Toggle slow keys	Hold Shift key by itself for eight seconds
Toggle sticky keys	Press and release the left or right Shift key five times in a row, without any intervening key events and with less than 30 seconds delay between consecutive presses
Turn off sticky keys	Simultaneously press two or more modifier keys.

2.6 Enhanced Access Control

HP DECwindows Motif for HP OpenVMS Alpha Version 1.3 offers support for additional security mechanisms that provide greater control over access to the server by remote applications. Both the DECwindows Motif client software and the DECwindows X11 Display Server have been modified to support the following:

• Enhanced user-based access control -- The existing user-based authorization mechanism has been extended to support DECwindows Motif systems that operate without a login process, as described in Section 2.6.1.
• Token-based access control -- This includes the use of the MIT-MAGIC-COOKIE-1 and MIT-KERBEROS-5 authentication protocols when clients connect to the X server, as described in Section 2.6.2.
• Use of the SECURITY extension -- Using the SECURITY extension, you can further restrict or extend the access of certain client applications, as described in Section 2.6.5.

The following sections describe the available access control schemes and how to use them to manage access to the DECwindows X11 Display Server.

2.6.1 User-Based Access Control

User-based access control, as described in Chapter 12 of Using DECwindows Motif for OpenVMS, authorizes access to the X server based on the triplet of host, transport, and user name (such as, DECNET ZEPHYR JONES). The user name, node name, and transport information you provide acts as a filter to screen out all except a selected class of users.

User-based access control can be implemented one of two ways depending on your DECwindows Motif system environment:

• For access control outside a DECwindows Motif session, use the access allowed and access trusted files, as described in Section 2.6.3.1.4.
• For access control inside a DECwindows Motif session, use the Security Options dialog box to add users to the Authorized Users list, as described in Section 2.6.3.2.1.

User-based access control is always available, as long as there are entries in either the Authorized Users or access allowed list. Due to lack of encryption and the inability to specify usernames in the TCP/IP environment, this form of access control is the least secure and is recommended for authorizing access in the local or DECnet environment only.

2.6.2 Token-Based Access Control

Token-based access control authorizes access to the X server based on the presentation of a valid password or token by a client application during a connection request. The level to which the client is authenticated and the method of authentication varies depending on the protocol in use, which is specified in a user's X authority file (described in Section 1.2.2.1).

In general, each time a client application attempts to connect to an X server protected with token-based access control, it references the current X authority file to determine the appropriate protocol to apply and authentication method to follow in order to grant the connection.

Not only do token-based protocols offer greater protection for DECwindows X11 Display Server systems, but they also provide more control over the operations that can be performed over an open X server connection. For example, a token could be used to grant or deny trust privileges. Untrusted connections to an X server significantly restrict the operations that can be performed over the connection.

The token-based access control protocols supported by DECwindows Motif are Magic Cookie (MIT-MAGIC-COOKIE-1) and Kerberos (MIT-KERBEROS-5).