HP OpenVMS Systems Documentation

HP DECwindows Motif for OpenVMS
Management Guide

Enabling access control outside of a DECwindows Motif desktop session allows authorized OpenVMS users to run client applications on systems without a login process. This type of access control is used typically for systems that function as a standalone X display server, rather than an interactive DECwindows Motif workstation.

Use the server customization parameters and either the access allowed file or X authority file to set access control.

3.3.6.2 Applying Access Control to Connections Inside a Desktop Session

Use the Security Options dialog box to set the access control scheme in effect inside a DECwindows Motif session. The options in the dialog box enable you to set the access control scheme used by the local X display server, to authorize other users access to the display server, and to specify the scheme local client applications use when connecting to a display server.

Accessed from the Session Manager (Traditional Desktop) or Style Manager (New Desktop), the settings in the Security Options dialog box are identical. Note, however, that each desktop stores the settings differently:

• Settings in the Traditional Desktop are stored in the DECW$SMB_SECURITY.DAT file as soon as the changes are applied.
• Settings in the New Desktop are saved whenever a session is saved (such as when saving a new home session or when saving the current session). Note that on the New Desktop, if you chose to restore the home session on next login, any changes will be lost unless you save them by updating the home session.

The following sections describe how to apply user-based access control to server connections outside and inside a desktop session.

Note that user-based access control over the TCP/IP Services transport uses the getnameinfo function to obtain the name of the peer system and matches this value against the values supplied by the user. If the address is an IPv4-mapped IPv6 address, the getnameinfo is called using the AF_INET family and the IPv4 address extracted from the IPv4-mapped IPv6 address. Otherwise, the getnameinfo function is called with AF_INET6 and the IPv6 address. IPv4 connections that fail reverse name translation are represented in IPv4 format. All other connections that fail reverse name translation are represented in IPv6 format.

If the address used is link local, a scope identifier is included in the string returned by the TCP/IP Services getnameinfo function. The server matches this against a host name in the authorized users list regardless of whether the enter contains a scope identifier or not. For example, a returned value of test12i6%WE1 matches either test12i6%WE1 or test12i6.

For Server Connections Outside a Desktop Session

To apply user-based access control to server connections made from outside of a DECwindows Motif session, do the following:

1. Modify the SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM file and define the value of the DECW$SERVER_ACCESS_ALLOWED and DECW$ACCESS_TRUSTED parameters so that they refer to the location where the files are stored, such as:

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

2. Create and edit the access allowed and access trusted files adding the appropriate user entries. Each entry follows the transport-host-username format. Note that the only valid transport values are DECNET, TCPIP, and LOCAL. The transport synonyms TCP, INET, INET6, and DNET described in Table 4-1 are not supported.
   For example, the following entries grant user JONES local access to the server as well as network access from node ZEPHYR through the DECnet transport:

   DECNET ZEPHYR JONES LOCAL 0 JONES . . .

   
   Note that when using TCP/IP as the network transport, access and trust privileges can only be assigned to a host rather than to specific users. TCP/IP does not provide the user specification as part of the data provided on a remote connection.
   As a result, file entries for hosts using TCP/IP must contain an asterisk (*) for the user specification. This grants all users on a particular host system access privileges when they connect to the X display server using TCP/IP. For example, the following entry grants access to all users on node ZEPHYR through the TCP/IP transport:

   TCPIP ZEPHYR * . . .

3. Save the files and restart the server. The new access and trust privileges are applied automatically at system startup.

For Connections Inside a Desktop Session

To apply user-based access control to server connections made from inside a DECwindows Motif desktop session:

1. Do one of the following, depending on the desktop:
   • From the Traditional Desktop, choose Security... from the Session Manager Options menu.
   • From the New Desktop, click the Style Manager Security control.
   
   The Security Options dialog box is displayed.
2. Under Server Access Control, click Users... to display the Configure Users dialog box.
3. Type the node, the username, and the method of transport for the users you want to authorize.
4. Click on the Add button. The users are added to the Authorized Users list.
5. Click on OK to save and apply the changes and close the Configure Users dialog box.

To disable user-based access control, you must remove all users from the Authorized Users list.

To remove a user name, first click on the names you want to remove. Then click on the Remove button. Finally, click on OK or Apply. The users will no longer have authorized access to the system.

3.3.8 Enabling Magic Cookie Access Control

The following sections describe how to apply Magic Cookie access control to server connections outside and inside a desktop session.

For Connections Outside a Desktop Session

To apply Magic Cookie access control to server connections made from outside of a DECwindows Motif session, do the following:

1. Log into the SYSTEM account or another privileged account.
2. Modify the DECW$PRIVATE_SERVER_SETUP.COM file and define the value of the DECW$SERVER_XAUTHORITY parameter so that it refers to the location where the X authority file will be stored, for example:

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

3. Using the X Authority File utility (xauth), manually create the X authority file for the server and add the appropriate entries. For example, the following command creates the new X authority file SERVER_ZEPHYR.DECW$XAUTH, adds the entry for the local transport, specifies the Magic Cookie protocol, and assigns a cookie value of 12345abcdef56789:

   $ XAUTH -f SYS$SYSROOT:[SYSMGR]SERVER_ZEPHYR.DECW$XAUTH ADD - _$ :0 MIT-MAGIC-COOKIE-1 12345abcdef56789

   
   The cookie in this file is loaded into the X server at start up and can be used to authorize all client connections.
4. Save the file and restart the server.
5. Propagate the key to all client systems using the xauth utility. For additional information on using the xauth utility, see the HP DECwindows Motif for OpenVMS New Features manual or refer to the online help.

For Connections Inside a Desktop Session

To apply Magic Cookie access control to server connections made from inside of a DECwindows Motif session, do the following:

1. Do one of the following, depending on the desktop:
   • From the Traditional Desktop, choose Security... from the Session Manager Options menu.
   • From the New Desktop, click the Style Manager Security control.
   
   The Security Options dialog box is displayed.
2. Under Server Access Control, choose the Magic Cookie option.
3. Click on OK to save and apply the changes and close the Security Options dialog box.
4. Once enabled, a cookie is generated each time you log into the desktop. To grant other users access to the X display server, you must propagate the cookie to their X authority file using the xauth utility.
   For additional information on using the xauth utility, see the HP DECwindows Motif for OpenVMS New Features manual or refer to the online help.

To disable Magic Cookie, deselect the Magic Cookie option and click OK or Apply.

To prevent other users from accessing the current session using the current cookie value, click on the Create Cookie button. The new cookie value is added to your default X authority file.

In order to enable Kerberos, you must first have performed the following on the server system:

1. Installed and configured the TCP/IP for OpenVMS software with a domain name server.
2. Installed and configured the Kerberos Client for OpenVMS software, as described in the Kerberos Client for OpenVMS Installation Guide and Release Notes.
3. Obtained the following information:
   • Location of the KDC
   • The appropriate node, domain, and realm information for adding principals
   • Your principal name and password
4. Enabled the TCP/IP transport by defining the DECW$SERVER_TRANSPORTS parameter in SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP and then restart the server.
   Note that Kerberos access control is not supported in TCP/IP environments that use IPv6. If Kerberos and IPv6 are enabled, the server connection attempt will fail with a KERBEROS error indicating that the network address is invalid. To use Kerberos access control, specify the INET transport name (as described in Table 4-1). This forces the use of IPv4 addresses.

The following sections describe how to apply Kerberos access control to server connections outside and inside a desktop session.

For Connections Outside a Desktop Session

To apply Kerberos access control to server connections made from outside of a DECwindows Motif session, do the following:

1. Invoke the Kerberos Administration utility, as follows:

   $ KERBEROS/INTERFACE=DECWINDOWS/ADMIN

2. Create the following principal, keytab file, and keytab file entry. Refer to your Kerberos Client for OpenVMS documentation for information on how to use the Kerberos Administration Utility.
   • Create the principal x0/host@REALM, for example:

     x0/system@ORG.COMPANY.COM

   • Create the keytab file SYS$SYSROOT:[SYSMGR]DECW$X0.KEYTAB.
   • Create an entry in that keytab file for principal x0.
3. Modify the DECW$PRIVATE_SERVER_SETUP.COM file and define the values of the following parameters so that they refer to the location where the X authority file, access allowed, and access trusted files will be stored, for example:

   $ DECW$SERVER_XAUTHORITY == "SYS$MANAGER:SERVER_ZEPHYR.DECW$XAUTH" $ DECW$SERVER_ACCESS_ALLOWED == "SYS$MANAGER:DECW$SERVER_ZEPHYR_ACCESS_ALLOWED.DAT" $ DECW$SERVER_ACCESS_TRUSTED == "SYS$MANAGER:DECW$SERVER_ZEPHYR_ACCESS_TRUSTED.DAT"

4. Using the xauth utility, manually create the X authority file for the server, and add the appropriate entries. For example, the following command creates the new X authority file SERVER_ZEPHYR.DECW$XAUTH, adds the entry for the local transport, specifies the Kerberos protocol, and assigns a value that identifies the keytab file:

   $ XAUTH -f SYS$SYSROOT:[SYSMGR]SERVER_ZEPHER.DECW$XAUTH - _$ ADD :0 MIT-KERBEROS-5 - _$ """CS:X0,SYS$SYSROOT:[SYSMGR]DECW$X0.KEYTAB"""

5. Manually create an access trusted file in the location specified by the DECW$SERVER_ACCESS_TRUSTED parameter and add an entry for the SYSTEM account, as follows:

   * SYSTEM 0

6. Manually create an access allowed file in the location specified by the DECW$SERVER_ACCESS_ALLOWED parameter and place an entry in the file for each Kerberos principal you want to grant access to the server. Each entry for a Kerberos principal in an access allowed file follows the protocol-principal@realm-accessrights format, where accessrights can be NONE, ALL, or *.
   For example, the following entry in an access allowed file grants principal JONES access to the server through the TCP/IP transport:

   KERBEROS jones@ORG.COMPANY.COM ALL . . .

7. Save the file and restart the server.

For Connections Inside a Desktop Session

To apply Kerberos access control to server connections made from inside of a DECwindows Motif session, do the following:

1. Do one of the following, depending on the desktop:
   • From the Traditional Desktop, choose Security... from the Session Manager Options menu.
   • From the New Desktop, click the Style Manager Security control.
   
   The Security Options dialog box is displayed.
2. Click on the Configure Principals button.
3. Enter the specification(s) for the Kerberos principal(s) you want to add to the Authorized Principals list.
   The format of a typical Kerberos principal is primary/instance@REALM.
4. Click on the Add button. The principal is added to the Authorized Principals box.
5. Click on OK to save and apply the changes and close the Configure Principals dialog box.
6. Under Server Access Control, choose Kerberos and click OK.
   The Kerberos Login dialog box is displayed, and you are prompted to log in and verify your Kerberos credentials.
7. Enter your Kerberos principal name and password and click OK. Note that principal names and passwords are case-sensitive.

To disable Kerberos, deselect the Kerberos option, remove all principals from the list, and click OK or Apply.

To prevent one or more principals from accessing your session, first click on the name(s) you want to remove. Then click on the Remove button. Finally, click on OK or Apply. The principal will no longer have authorized access to your workstation.

If you believe the current ticket has been compromised, you can deny access to your session and force principals to repeat the login and authentication process by clicking on the Revoke Ticket button.

3.3.10 Using the Security Extension

The Security extension (SECURITY) enables you to manually generate authorization keys using the xauth utility or the SET DISPLAY/GENERATE command. This allows you to specify one of the following additional attributes to apply to a server connection:

• UNTRUSTED -- Indicates that this is an untrusted connection. An untrusted connection severely restricts the operations that can be performed over the connection. Client applications running over an untrusted connection are allowed limited access to X server extensions and are prevented from accessing windows other than those created by the application. This is the default attribute for all authorization keys.
• TRUSTED -- Indicates that this is a trusted connection. A trusted connection allows all client operations (except those that change access control parameters) to occur over the connection.
• TIMEOUT -- Sets an expiration period for the token.
• GROUP -- Indicates the application group to which the token applies.

To enable the Security extension, modify the SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM file and redefine the DECW$SERVER_EXTENSIONS parameter so that it includes a value of "SEC_XAG." For example:

$ decw$server_extensions == "SEC_XAG"

Save the file and restart the server.

3.3.10.2 Using the Security Policy File

The security policy file enables you to configure the server to allow certain actions (at the X atom level) to be performed over untrusted network connections. This file establishes one or more site policies that specify the set of allowable actions through a series of field definitions.

A sample file has been provided with DECwindows Motif and is located in DECW$EXAMPLES:DECW$SECURITY_POLICY.TXT. Use this file as a template when creating a policy file. Security policies are described in the Security Extension Specification published by the X.Org Foundation. Refer to this specification for details regarding the use and definition of security policies.

To establish a security policy file on a DECwindows Motif system, do the following:

1. Copy DECW$EXAMPLES:DECW$SECURITY_POLICY.TXT to another file, make the necessary changes, and save the file to an alternate location on the system.
2. Modify the DECW$PRIVATE_SERVER_SETUP.COM file, and define the value of the DECW$SECURITY_POLICY parameter to point to the location where security policy file resides.
3. Save the file and restart the server.

Multihead systems enable you to connect multiple monitors to a system to form a single display. The following sections describe the system setup prerequisites and the supported methods for configuring multihead systems.

3.4.1 System Setup

Before setting up a multihead system, you must first do the following:

1. Disable VGA services. -- Some video cards can dynamically disable or enable VGA services as necessary, but others require that you manually disable VGA using 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 system.

   Warning If you install multiple video cards on a system without disabling VGA services on all but one of the cards, all of the cards will compete for control of the video subsystem at boot time, resulting in possible system damage.

2. Install the video cards. -- Shut down the OpenVMS 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 operating system will verify that the video cards were installed correctly.

The DECW$PRIVATE_SERVER_SETUP.TEMPLATE file includes the following command to set up your system for multihead use:

$ IF DECW$DEVICE_COUNT .GT. 1 THEN DECW$MULTI_HEAD == 1

The template file is located in the SYS$MANAGER directory. To invoke multihead support, copy the template file to SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM. Editing of this file is not needed.

3.4.3 Configuring a Multihead System Using XINERAMA

The Xinerama extension (XINERAMA) enables you to connect multiple monitors to a single system running to create a unified virtual display. In contrast to simple multihead systems, XINERAMA provides control over the arrangement of the screens and desktop. You can customize the number, order, and configuration of each screen in the display, and you can drag windows and text from screen to screen on the desktop.

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

3.4.3.1 Hardware and Configuration Requirements

XINERAMA is supported only in a homogeneous graphics environment. Each multihead configuration must consist of common video cards, bit depths, visual classes, screen resolutions, and monitors of a similar size. The monitors must also be arranged into a rectangle--without gaps in between.

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

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