HP OpenVMS Systems Documentation

To enable Magic Cookie and grant one or more clients presenting a valid magic cookie access to your workstation display:

1. Do one of the following, depending on the desktop:
   • From the Traditional Desktop, choose Security... from Session Manager's 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.
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 server, you must propagate the cookie to their X authority file using the xauth utility, as described in Section 1.2.2.6.

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.

Prerequisites

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

1. Installed and configured the TCP/IP for OpenVMS Alpha 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 SECURITY extension and TCP/IP transport by defining the DECW$SERVER_EXTENSIONS and DECW$SERVER_TRANSPORT parameters in SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP and restarting the server.

To enable Kerberos, and grant one or more valid Kerberos principals access to your workstation display:

1. Do one of the following, depending on the desktop:
   • From the Traditional Desktop, choose Security... from Session Manager's 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.

To prevent all principals from accessing your session, click on the Revoke Ticket button, and click OK or Apply.

2.6.4 Specifying Client Access Control

When a client application connects to an X server, the server determines which authentication protocol to use by accessing the current X Authority file. The X Authority file identifies the protocol to use based on the workstation to which the client is connecting. You can make changes to the X authority file using the Security Options dialog box or by directly using the X authority file, as described in Section 1.2.2.

To specify what access control scheme client applications on this workstation follow when connecting to an X server:

1. Do one of the following, depending on the desktop:
   • From the Traditional Desktop, choose Security... from Session Manager's Options menu.
   • From the New Desktop, click the Style Manager Security control.
   
   The Security Options dialog box is displayed.
2. Under Client Access Control, choose one of the following:
   • Authorized Users List
   • Kerberos
   • Magic Cookie
3. Click on OK to save and apply the changes and close the Security Options dialog box.
   All subsequent client applications run from this system by the current user will apply this access control scheme when connecting to local X servers.

   Note Changes to client access control settings impact the contents of the default X authority file entries (local and DECnet) for the current user only, and do not impact any other access control settings in place on the system.

Using the SECURITY extension (described in Section 3.5.1.6), you can choose to manually generate authorization keys using xauth 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 a 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 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:

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

   $ DECW$SERVER_EXTENSIONS == "SEC_XAG"

3. Save the file and restart the server.

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 Version 7.1 published by X.Org. 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. Edit the DECW$PRIVATE_SERVER_SETUP.COM file.
3. Define the value of the parameter DECW$SECURITY_POLICY to point to the location where security policy file resides.
4. Save the file and restart the server.

2.7 Support for Low-Bandwidth X (LBX)

The components of the LBX implementation in DECwindows Motif (see Figure 2-1) are as follows:

• LBX-Enabled X Server---The use of LBX requires that the X server be capable of interpreting the LBX protocol. On DECwindows Motif systems, you must enable the use of the LBX protocol through the DECW$SERVER_EXTENSIONS server customization parameter. For more information about enabling LBX on an DECwindows Motif X server, see Section 2.1.
• Proxy Server---The proxy server appears to clients as any other X server. The proxy server accepts a connection request from a client program and acts as an intermediary between the client and the X server. Communication between the proxy server and the client uses the standard X protocol. Communication between the proxy server and the X server uses an LBX-enhanced X protocol.
• Proxy Manager---The proxy manager relieves clients from managing proxy servers. Instead of sending a request directly to a proxy server, the client sends a request to the proxy manager indicating the requested X server. The proxy manager is responsible for either using an existing proxy server or starting a new proxy server. Once the manager finds a proxy server it returns the proxy server's address to the client. The proxy manager is optional.
• DCL SET and SHOW DISPLAY Enhancements---The SET DISPLAY command has been modified to include qualifiers that allow users to specify either a proxy manager or a proxy server. The changes also provide a method for supplying proxy authentication data. The SHOW DISPLAY command has been modified to display proxy information as well as proxy authentication information. For more information about the changes to the SET DISPLAY and SHOW DISPLAY commands, see Section 1.1.1.

Figure 2-1 LBX Components

Proxy servers can be categorized as one of the following according to their relation to the proxy manager:

• Managed -- The proxy server is managed by a proxy manager. The proxy server can be used by multiple clients to access multiple X servers. Clients do not need to know the proxy server's server number, they simply provide the requested X server to the proxy manager. The manager, in turn, either finds the appropriate existing proxy server or automatically starts a new instance of the proxy server.
• Unmanaged -- The proxy server is started manually. The proxy manager is aware of the server. The server can be used by multiple clients to access multiple display servers.
• Standalone -- The proxy server is started manually. The proxy manager is not aware of the server. The server can be used by multiple clients to access a single X server. Clients need to know the proxy server's number.

Note the DECwindows Motif LBX proxy server is currently supported only as a managed or standalone configuration.

2.7.1.1 Starting LBX Proxy Servers

How you start an LBX proxy server determines the proxy server's type and how a client accesses the proxy server.

Managed Proxy Servers

To start a managed LBX proxy server, place the following LBX service entry in the proxy manager's configuration file (see Section 2.7.2.1).

LBX MANAGED COMMAND SYS$MANAGER:DECW$LBXPROXY_SUB ["qualifiers"]

After the proxy manager is configured, no specific action is required to start the proxy server; the proxy manager starts the server when the manager receives the first client request.

Standalone Proxy Servers

You can start standalone LBX proxy servers either in the current process or as a detached process. To start a standalone proxy server in the current process, use the LBXPROXY command.

LBXPROXY [qualifiers]

For example, to start a proxy server in the current process, assign it server number 50, and have the server act as a proxy for the X server on node remote1.cmp.com, use the following command:

$ LBXPROXY /DISPLAY="REMOTE1.CMP.COM:0"/SERVER=50/FIXED_SERVER

To start a proxy server as a detached process, use the DECW$LBXPROXY command procedure.

@SYS$MANAGER:DECW$LBXPROXY ["lbxproxy-qualifiers"] ["run-qualifiers"]

For example, to start a proxy server as a detached process, assign it server number of 50, and have the server act as a proxy for the X server on node remote1.cmp.com, use the following command:

$ @SYS$MANAGER:DECW$LBXPROXY "/DISPLAY=""REMOTE1.CMP.COM:0""" + -
_$ "/SERVER=50/FIXED_SERVER"

Use the run-qualifiers parameter to pass any qualifiers to the RUN command used to invoke the LBXPROXY image. One use of this parameter might be to override the default LBXPROXY process characteristics or any values set by the logicals provided to modify these defaults.

Modifying the Default LBXPROXY Process Characteristics

Table 2-2 lists the logicals that are provided to override the default LBXPROXY process characteristics specified on the RUN command generated by SYS$MANAGER:DECW$LBXPROXY.

Enter LBXPROXY command qualifiers in the same manner as you would for any other DCL command. For managed servers, specify these qualifiers on the LBX service line in the proxy manager's configuration file.

/ATOMS=file-specification

Specifies the file that the proxy server should use for atoms control. The file SYS$MANAGER:DECW$ATOMCONTROL.TEMPLATE contains an example of an atom control file. This qualifier cannot be specified if the NOATOMS or NOLBX option is specified for the /OPTION qualifier.

The default is /ATOMS=SYS$MANAGER:DECW$ATOMCONTROL.DAT. However, effectively the default is not to use atom control because the installation process does not convert the SYS$MANAGER:DECW$ATOMCONTROL.TEMPLATE file to the SYS$MANAGER:DECW$ATOMCONTROL.DAT file.

At startup, the LBX proxy server "pre-interns" the atoms specified in the atom control file. The atom control file also controls when the proxy server should delay sending data to the X server. This is done by specifying the following:

• Minimum data length required before the server delays any data.
• Which atoms should be delayed only when a window manager is running on the same connection.

The format of the atom control file is documented in the SYS$MANAGER:DECW$ATOMCONTROL.TEMPLATE file.

/CHEAT={ERRORS | EVENTS | NONE}

Specifies the level of cheating allowed on the X protocol for the sake of improved performance. The X protocol guarantees to the requesting party that all corresponding replies, events, or errors are returned to the requester in the same order as the original requests. The ERRORS option allows the proxy server to violate the X protocol with respect to errors. The EVENTS option allows the proxy server to violate the X protocol with respect to errors and events. The NONE option specifies that no protocol cheating is allowed.

The default is /CHEAT=NONE.

/DISPLAY={"network-address" | logical-name | device-name}

Specifies a network address, logical name, or device name that references the X server to which the proxy server should connect. A network address must be in the following form:

"[transport\][node][:]:display[.screen]"

This option is ignored for managed proxy servers.

The default is /DISPLAY=DECW$DISPLAY.

/FIXED_SERVER
/NOFIXED_SERVER

Specifies that the proxy server should fail to start if the server number specified by the /SERVER qualifier is not available. See /SERVER qualifier for more information about server numbers. This option is useful for starting standalone servers as detached processes. In this case, the proxy server has no method to return the selected server number. This option is ignored for managed proxy servers.

The default is /NOFIXED_SERVER.

/MAXSERVER=value

Specifies the maximum number of X servers to which this proxy server can connect. This option is ignored for standalone servers. Specify a value from 1 to 63.

The default is /MAXSERVER=20.

/MOTION=value

Specifies the maximum number of pointer motion events that are allowed to remain unanswered between the proxy server and the X server. Specify a value from 1 to 32767.

The default is /MOTION=8.

/ONERROR={RECONNECT | TERMINATE}

Specifies the action taken when the proxy server encounters an internal error. This usually occurs when the proxy server looses its connection to the X server.

The default is /ONERROR=TERMINATE.

/ONEXIT={NOACTION | RESET | TERMINATE}

Specifies the action taken by this proxy server when the last client exits.

The default is /ONEXIT=NOACTION.

/OPTIONS=(option-list)

Specifies the optimizations to use for this proxy server. With the exception of ALL and NONE, each option has a NOoption form that disables the option. To enable a small number of options, use a combination of the NONE and the desired options. For example, /OPTIONS=(NONE,IMAGE) suppresses all optimization with the exception of image compression. To disable a small number of options, use a combination of the ALL and the undesired options. For example, /OPTIONS=(ALL,NOIMAGE,NOGRAPHICS) suppresses image and graphics optimization.

The default is /OPTIONS=ALL.

/PARTIAL
/NOPARTIAL