HP OpenVMS Systems Documentation
HP DECwindows Motif
The program contains the following limitations:
Program limitations with an LN03 printer:
Program limitations with a LA100 printer:
Program limitations with an HP printer:
xpr -density 96 -width 6.667 filename
xpr -density 180 filename
This chapter provides information about new features and enhancements
related to DECwindows Motif system management.
3.1 Installation and Upgrade Information
The following sections describe features that pertain to installing and
upgrading DECwindows Motif systems.
3.1.1 Version Checking Available for Command Files
The DECwindows Motif kit contains version-checking command procedures that layered products can use during their installation procedure. The following three files are placed in the SYS$UPDATE directory during the installation of DECwindows Motif:
Use the following command to display the versions on sys$output:
$ @SYS$UPDATE:DECW$VERSIONS *
|DECwindows ident||Xlib shareable image|
|DECwindows server||Server DIX file|
|DECwindows transport||Transport common|
|DECwindows Xlib||Xlib shareable image|
|DECwindows OSF/Motif Toolkit||OSF/Motif Xm Toolkit|
|DECwindows applications||DECwindows FileView|
|DECwindows programming||OSF/Motif UIL compiler|
This section describes features related to tuning and customizing the
DECwindows Motif environment.
3.2.1 Setting the File Manager Refresh Rate
You can now specify that the File Manager periodically update its view
on the New Desktop by adjusting the Dtfile.rereadTime
setting in the DTFILE.DAT resource file. The value of this setting
represents the seconds elapsed between checking for changes in the
viewed directories. Note that this setting does not work when viewing
3.3 Security and Authorization
The following sections describe features that pertain to maintaining
system and network security of DECwindows Motif systems.
3.3.1 Enhanced Access Control
DECwindows Motif 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:
The following sections describe the available access control schemes
and how to use them to manage access to the DECwindows X11 Display Server.
126.96.36.199 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:
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
188.8.131.52 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 184.108.40.206).
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).
MIT-MAGIC-COOKIE-1 and MIT-KERBEROS-5 are standard X Window System protocols. Third-party client applications can use these protocols to connect to protected DECwindows X display servers and DECwindows Motif clients can use them to connect to protected third-party X display servers. Additional X Window System protocols, such as XDM-AUTHORIZATION-1 and SUN-DES-1, are not currently supported. Any third-party client applications using these protocols to access a DECwindows X display server will default to user-based access control.
The MIT-MAGIC-COOKIE-1 protocol was designed to provide a more secure alternative to the host-based security mechanism (xhost) available in previous releases of the X Window System. The first protocol to use a token-based approach, it provided the initial, standard means for restricting access to the X server on a user level.
Magic Cookie authorizes connections to an X server based on entries in the X authority file. Each entry for Magic Cookie access control specifies:
Magic Cookie access control can be implemented one of two ways depending on your DECwindows Motif system environment:
When Magic Cookie is used to authorize connections during a DECwindows Motif session, a cookie is generated each time a user successfully logs into their local DECwindows Motif desktop. The magic cookie authorizing the local connection, along with the device, transport, and protocol name is passed to the X server and stored in the current X authority file (SYS$LOGIN:DECW$XAUTHORITY.DECW$XAUTH).
Each time a client application attempts to connect to the X server during the session, the application must present a valid cookie to the X server along with the connection request. If the cookie matches the one maintained by the X server, the connection is authorized, access is granted to the X server, and the display is opened.
If the client does not present a valid cookie, the following message is displayed, and the connection is denied:
Xlib: connection to "0:0.0" refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key X Toolkit Error: Can't Open display
When the user logs out of the DECwindows Motif session, the server is reset, and the cookie is discarded.
The basic authorization process remains the same when Magic Cookie is used to authorize X server connections outside of a DECwindows Motif session. However, the file creation process is not. Both the X authority file and the magic cookie must be manually generated.
Due to the use of a randomly-generated token, Magic Cookie provides a
more secure form of access control than the user-based scheme. However,
the cookies are sent across the network unencrypted, leaving them prone
to interception. As a result, this form of access control is
recommended for authorizing connections in a local area network (LAN)
or limited DECnet environment.
220.127.116.11.2 Kerberos (MIT-KERBEROS-5)
Kerberos authorizes connections to an X server based on a combination of the following:
Kerberos credentials, or tickets, are a set of electronic information that can be used to verify the identity of a principal. These principals are stored in an Authorized Principals list kept on the server system. With Kerberos, client applications run by a valid principal send requests for a ticket from the Kerberos Key Distribution Center (KDC) each time they attempt to connect to the Kerberos-protected X server.
Kerberos access control can be implemented one of two ways depending on your DECwindows Motif system environment:
Once Kerberos access control is enabled on the server, a new ticket is requested from the KDC automatically each time a user logs into their local desktop. The KDC creates a ticket-granting ticket (TGT) associated with the user's principal name, encrypts it using the password as the key, and returns the encrypted TGT.
If the TGT is decrypted successfully, the user is authenticated and the TGT is cached. The TGT permits the authenticated principal to obtain additional tickets. These additional tickets grant access to specific services, in this case, access to the X server from other client applications. The requesting and granting of these additional tickets happens transparently.
With DECwindows Motif, user-to-user authentication is employed. In this model, both the client and server use a Kerberos client at each end of the connection to verify the identify of the user (principal). Once the principal is authenticated at both ends of the connection, access is granted to the X server.
By default, each TGT expires at a specified time. If a TGT has expired or been compromised, you can choose to revoke the current TGT and generate a new TGT by forcing a Kerberos login.
The basic authorization process remains the same when Kerberos is used to authorize X server connections outside of a DECwindows Motif session. However, the credential initialization is not. The user who is running the client application must force initialization using the Kerberos Initialization utility (kinit) or by forcing a login through OpenVMS.
Kerberos is the most secure form of access control since it encrypts the initial authentication information between the requesting client and the server system. Therefore, it is the recommended method for authorizing remote client connections over unsecure networks, such as the Internet.
Kerberos is designed to generate a session key that can be used to encrypt all data transmitted over a network connection. The X Window System uses this key only to encrypt the initial authentication messages. Once the identity of the client has been reliably verified, all subsequent data is sent across the network channel unencrypted. As a result, the server itself can remain susceptible to some forms of network-level attacks.
When configuring access control for the X display server, you can choose to apply a traditional user-based scheme, a token-based scheme (such as Magic Cookie or Kerberos), or a combination of schemes depending upon your network environment. For example, you may choose to use Kerberos to authorize all remote server connections over TCP/IP and Magic Cookie to authorize LAN network connections.
When used in combination, the most restrictive access control scheme presented by the client always takes precedence. For example, if the server has all three schemes enabled, and the requesting client is using Magic Cookie, the server will attempt to authorize the connection via Magic Cookie. Note with Magic Cookie access control, user-based access is available by default. If the client attempts and fails to connect to the server using a token-based scheme and is also a member of the Authorized Users list, then access will be granted.
Before enabling access control, take the following actions:
|Verify that an access trusted file exists.||In order to change access control settings, one or more OpenVMS Alpha users must hold trust privileges for the DECwindows Motif system. Before enabling authentication, ensure that an access trusted file exists and that at least one account (such as, SYSTEM) has been granted trust privileges. For information about the access trusted file, see The Access Trusted File.|
|Determine the appropriate method for the DECwindows Motif environment.||Select the authentication method most appropriate to your DECwindows Motif environment, and enable that method only. For example, for DECwindows Motif systems that run applications outside of a desktop, only enable authentication outside of a DECwindows Motif session. Combining schemes can result in a situation where the initial DECwindows Motif login process cannot login.|
Enabling access control outside of a DECwindows Motif desktop session allows authorized OpenVMS users to run X Window System client applications on systems without a login process. This type of access control is used typically for systems that function as a standalone X server, versus an interactive DECwindows Motif workstation.
Use the server customization parameters and either the access allowed or X authority file to set access control, as described in the following sections.
By default, access to the DECwindows X11 Display Server prior to login is limited to the local SYSTEM account via the DECnet or local transport. The access allowed file is an ASCII text file that grants additional OpenVMS users access to the X server automatically at server startup.
The access allowed settings remain in effect until a user logs into a DECwindows Motif desktop. Once a user logs into a desktop and begins a DECwindows Motif session, any security options defined with the Session Manager for that user are applied. If a token-based access control scheme has been enabled, additional information may need to be provided by a client application or user in order to gain access to the X server. See Section 3.3.1 for more information on token-based schemes currently supported by DECwindows Motif.
Once the user ends the session, the server is reinitialized, and the access allowed settings are restored.
The access allowed file is intended for use on workstations that do not normally use the DECwindows Motif login process. Do not use this file on workstations that rely on the DECwindows Motif login process to restrict access to the X server, as it can compromise the security of the DECwindows Motif system.
For example, a user granted access via the access allowed file could spoof a login window that captures the passwords of other users attempting to log into a DECwindows Motif desktop.
Not to be confused with trusted network connections, as described in Section 18.104.22.168, trusted users are those who are authorized to change security settings. The access trusted file is an ASCII text file that identifies which OpenVMS users can change the access control settings for a particular DECwindows X11 Display Server.
By default, the local SYSTEM account is granted trust privileges (via the local or DECnet transport). However, when using token-based authentication, trust privileges are not assigned by default. You must manually assign these privileges using the access trusted file.
Entries in this file are automatically added to the access allowed list, unless a token-based authentication scheme is in place. In that case, trusted users must be granted access to the X server either through a manual entry to the access allowed list or via an entry in the appropriate X authority file. Similar to the settings in an access allowed file, access trusted settings remain in effect until a user logs into a DECwindows Motif desktop.
Depending on the access control method in place, the format of file entries can differ.
DECNET ZEPHYR JONES LOCAL 0 JONES . . .
TCPIP ZEPHYR * . . .
KERBEROS jones@ORG.COMPANY.COM ALL . . .
To apply user-based access control outside of a DECwindows Motif session, establish an access allowed and access trusted file, as follows: