|
HP OpenVMS Systems Documentation |
|
HP DECwindows Motif for OpenVMS
|
| Previous | Contents | Index |
You can use the X Display Information utility (xdpyinfo) to query the server directly and report various server parameters.
Before running this utility, make sure you have the correct display selected by using the SET DISPLAY command.
The following example shows how to invoke xdpyinfo and illustrates a typical display:
$ SET DISPLAY/CREATE/NODE=node_name $ RUN DECW$UTILS:XDPYINFO |
name of display: _WSA1:
version number: 11.0
vendor string: DECWINDOWS Hewlett-Packard Development Company OpenVMS
vendor release number: 8002
maximum request size: 65535 longwords (262140 bytes)
motion buffer size: 0
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 6
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 12, bits_per_pixel 32, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 255
number of extensions: 17
DEC-Server-Mgmt-Extension
ServerManagementExtension
SHAPE
MIT-SHM
Extended-Visual-Information
XTEST
BIG-REQUESTS
MIT-SUNDRY-NONSTANDARD
MIT-SCREEN-SAVER
SYNC
XC-MISC
TOG-CUP
Xie
DEC-XTRAP
Multi-Buffering
SECURITY
XC-APPGROUP
default screen number: 0
number of screens: 1
screen #0:
dimensions: 1280x1024 pixels (325x260 millimeters)
resolution: 100x100 dots per inch
depths (1): 8
root window id: 0x2e
depth of root window: 8 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x21
default number of colormap cells: 256
preallocated pixels: black 0, white 1
options: backing-store YES, save-unders YES
current input event mask: 0x0
number of visuals: 10
default visual id: 0x22
visual:
visual id: 0x22
class: PseudoColor
depth: 8 planes
size of colormap: 256 entries
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x23
class: PseudoColor
depth: 8 planes
size of colormap: 256 entries
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x24
class: DirectColor
depth: 8 planes
size of colormap: 8 entries
red, green, blue masks: 0xe0, 0x1c, 0x3
significant bits in color specification: 3 bits
visual:
visual id: 0x25
class: GrayScale
depth: 8 planes
size of colormap: 256 entries
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x26
class: StaticGray
depth: 8 planes
size of colormap: 256 entries
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x27
class: StaticColor
depth: 8 planes
size of colormap: 256 entries
red, green, blue masks: 0xe0, 0x1c, 0x3
significant bits in color specification: 8 bits
visual:
visual id: 0x28
class: TrueColor
depth: 8 planes
size of colormap: 8 entries
red, green, blue masks: 0xe0, 0x1c, 0x3
significant bits in color specification: 3 bits
visual:
visual id: 0x29
class: TrueColor
depth: 8 planes
size of colormap: 8 entries
red, green, blue masks: 0xe0, 0x1c, 0x3
significant bits in color specification: 3 bits
visual:
visual id: 0x2a
class: TrueColor
depth: 8 planes
size of colormap: 8 entries
red, green, blue masks: 0xe0, 0x1c, 0x3
significant bits in color specification: 3 bits
visual:
visual id: 0x2b
class: TrueColor
depth: 8 planes
size of colormap: 8 entries
red, green, blue masks: 0xe0, 0x1c, 0x3
significant bits in color specification: 3 bits
|
Use the X Set utility (xset) to query the server directly for parameter settings. Running xset is a good method to determine the current font path.
Before running this utility, make sure you have the correct display selected by using the SET DISPLAY command.
The following command shows how to invoke xset and illustrates a typical display:
$ SET DISPLAY/CREATE/NODE=node_name $ MCR DECW$UTILS:XSET Q |
Keyboard Control:
auto repeat: on key click percent: 25 LED mask: 00000000
auto repeating keys: 0000000000000000
0000c0ffffffffff
ffffffffff27f8ff
ffffffffffffffff
bell percent: 0 bell pitch: 400 bell duration: 100
Pointer Control:
acceleration: 7/1 threshold: 3
Screen Saver:
prefer blanking: yes allow exposures: yes
timeout: 600 cycle: 600
Colors:
default colormap: 0x21 BlackPixel: 0 WhitePixel: 1
Font Path:
DECW$SYSCOMMON:[SYSFONT.DECW.CURSOR32],DECW$SYSCOMMON:[SYSFONT.DECW.CURSOR16],
DECW$SYSCOMMON:[SYSFONT.DECW.100DPI],DECW$SYSCOMMON:[SYSFONT.DECW.75DPI],
DECW$SYSCOMMON:[SYSFONT.DECW.USER_COMMON],DECW$SYSCOMMON:[SYSFONT.DECW.COMMON],
DECW$SYSCOMMON:[SYSFONT.DECW.SPEEDO],DECW$SYSCOMMON:[SYSFONT.DECW.TYPE1],
DECW$SYSCOMMON:[SYSFONT.DECW.TRUETYPE],
CDE$SYSTEM_DEFAULTS:[CONFIG.XFONTS.C.100DPI],
CDE$SYSTEM_DEFAULTS:[CONFIG.XFONTS.C.75DPI],
CDE$SYSTEM_DEFAULTS:[CONFIG.XFONTS.C]
Bug Mode: compatibility mode is enabled
|
As illustrated in Chapter 1, the DECwindows transport interface is a general data-transfer mechanism for moving X protocol requests between a client and server.
The following sections briefly describe the supported transports and
how to enable them for use by the X display server. See Section 4.1
for information about how to set the transport for the client.
3.2.1 Using the Local Transport
The local transport is the default network transport, which is always
available. Use local transport when a DECwindows client and the display
server are running on the same OpenVMS system. The local transport
generally improves performance because data is transferred between
client and server more directly through shared memory. This mechanism
reduces the number of data copies in the system and eliminates the
extra overhead incurred by network access.
3.2.2 Using the DECnet Transport
DECwindows also provides support for the DECnet transport. Before you can enable and use this transport, either the HP DECnet Phase IV for OpenVMS or HP DECnet-Plus (Phase V) for OpenVMS software must be installed and running on the system.
See the DECnet product documentation for information on installing and running the networking software.
If DECnet or TCP/IP is shut down while the server is attached to it, the transport will continuously poll the network to reattach when the network is restarted. |
DECwindows Motif supports both the Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) implementations of the TCP/IP transport, as described in Chapter 4. Before you can enable and use this transport, the HP TCP/IP Services for OpenVMS software or a supported third-party TCP/IP product must be installed and running as part of system startup.
The TCP/IP Services software is configured to run at system startup by default. If you are using a third-party product, see the product documentation for instructions on how to install and configure the software.
You can conserve memory and process slots by configuring HP TCP/IP
Services for OpenVMS software for the minimum DECwindows requirement to
support the X protocol. DECwindows only requires that INET_ACP be
running. For more information about TCP/IP concepts and configuring the
network software, see the TCP/IP Services for OpenVMS documentation.
3.2.4 Using the LAT Transport
DECwindows supports LAT as a network transport mechanism for displaying to other OpenVMS Alpha and OpenVMS I64 workstations. Before you can enable and use LAT transport, you must start the LAT software on both the DECwindows client and server systems. Refer to the LATCP Utility Reference Manual for details on starting and configuring the LAT software.
In order to use LAT as a transport, the LAT service X$SERVER must be present on the display server system. Define the following logical to force the DECwindows startup procedure to create the LAT service:
$ DEFINE /SYSTEM DECW$INSTALL_XTERMINAL SERVER |
You must define this logical before DECwindows is started. HP suggests
that you define this logical in SYS$MANAGER:SYLOGICALS.COM.
3.2.5 Changing the Default Transports
The DECnet and local transports are enabled by default. To enable or disable transports for your display server, modify the DECW$PRIVATE_SERVER_SETUP.COM file and redefine the DECW$SERVER_TRANSPORTS parameter.
Example 3-1 shows a sample setup for a system to use TCP/IP and local connections but not DECnet connections.
| Example 3-1 Sample Setup for Transport Connections |
|---|
$do_TCPIP: $ decw$server_transports == "TCPIP,LOCAL" $ exit $ ! |
The following sections describe the access control schemes supported by
DECwindows Motif and how to use them to manage access to the X display
server.
3.3.1 User-Based Access Control
User-based access control authorizes access to the X display 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 is always available, as long as there are
entries in either the authorized users list 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 local, DECnet, or LAT
environments only.
3.3.2 Token-Based Access Control
Token-based access control authorizes access to the X display 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: Magic Cookie (MIT-MAGIC-COOKIE-1) or Kerberos (MIT-KERBEROS-5).
In general, each time a client application attempts to connect to a server protected with token-based access control, it references an 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, but they also provide more control over the operations that can be performed over an open server connection. For example, a token could be used to grant or deny trust privileges. Untrusted connections to an X display server significantly restrict the operations that can be performed over the connection.
Additional X Window System security 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. |
Magic Cookie was designed to provide a more secure alternative to the host-based security mechanism 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 display server on a user level.
Magic cookie authorizes connections to a server based on a client presenting a binary numeric value, known as a cookie, to the server. Normally, the client obtains this cookie value from an X authority file; however, some programs may use alternate mechanisms.
Each entry in the X authority file for Magic Cookie access control specifies:
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 display 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 display server during the session, the application must present a valid cookie to the server along with the connection request. If the cookie matches any one of the cookies maintained by the X display server, the connection is authorized, access is granted, and the display is opened. When the user logs out of the DECwindows Motif session, the server is reset, and the cookie is discarded.
Due to the use of a randomly-generated value, 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 across local area networks
(LANs), limited DECnet environments, across TCP/IP networks that have
been secured using another form of protection.
3.3.2.2 Kerberos
Kerberos authorizes connections to an X display 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 display server.
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 display 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 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.
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. |
The X authority file is a binary data file that contains information used to authorize connections to the X display server. Each time a client application attempts to connect to an X server, it references the current X authority file to determine the appropriate authorization key to apply in order to authenticate the connection.
Each authorization key consists of the protocol name and token, which can be one of the following depending on the protocol in use:
By default, an X authority file is created automatically the first time a user logs into a desktop on a system configured for Magic Cookie or Kerberos access control. The file is stored in that user's OpenVMS login directory (SYS$LOGIN:DECW$XAUTHORITY.DECW$XAUTH). Each time the user subsequently logs into a desktop on that system, a new authorization key is generated, passed to the X display server, and written to the user's X authority file. This key controls access to the X display server during the DECwindows Motif session.
A separate X authority file can be defined manually (using the DECW$SERVER_XAUTHORITY symbol) for those client applications that require access to a server outside of the normal DECwindows Motif login process.
If the Security extension is enabled, authorization keys can also be manually generated. Manually-generated keys can be used to further restrict server access. The generated key is stored in the X authority file on the client system overwriting any value already present for the specified display server. The key can be distributed to different client systems to allow connections to a specific server and can be revoked to stop subsequent connections.
Generated keys are assigned an authorization ID that
associates the key with the user who generated the key. As a result,
only the user who generated the key can revoke the key.
3.3.4 The Access Allowed File
The access allowed file is an ASCII text file that grants additional OpenVMS users access to the X display 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 by the Session Manager for that user are applied.
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 through an access allowed file could spoof a login window that captures the passwords of other users attempting to log into a DECwindows Motif desktop. |
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 display server.
By default, the local SYSTEM account is granted trust privileges (over the local or DECnet transport). 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 display server either through a manual entry to the access allowed list or through 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.
3.3.6 Choosing an Access Control Method
When configuring access control for the X display server, you can choose to apply one 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 that 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 but is also a member of the authorized users list, then access will still be granted.
However, before enabling an access control scheme, you must first determine the server connection environment, as described in the following sections. For example, some DECwindows Motif systems only run applications outside of a desktop session. For these systems, you should apply access control only to connections made outside of a DECwindows Motif session. Applying access control to connections both inside and outside a desktop session can result in a situation where the initial DECwindows Motif login process cannot login.
| Previous | Next | Contents | Index |