HP OpenVMS Systems Documentation

The program contains the following limitations:

• Support for PostScript output currently cannot use the -append, -noff, or -split options.
• The -compact option is only supported for PostScript output. It compresses white space but not black space, so it is not useful for reverse-video windows.
• For color images, map directly to PostScript image support.

Program limitations with an LN03 printer:

• The current version of xpr can print most X Windows that are not larger than two-thirds of the screen.
  For example, the LN03 prints a large Emacs window, but fails when trying to print the entire screen.
• The LN03 has memory limitations that cause it to incorrectly print large or complex windows. The two most common errors encountered are "band too complex" and "page memory exceeded" and are described as follows:
  • "band too complex"
    A window may have a particular six pixel row that contains too many changes (from black to white to black). This causes the printer to drop part of the line and possibly drop parts of the page. The printer flashes the number "1" on its front panel when this problem occurs. A possible solution to this problem is to increase the scale of the picture or to split the picture onto two or more pages.
  • "page memory exceeded"
    This occurs if the picture contains too much black space, or if the picture contains complex half-tones, such as the background color of a display. When this problem occurs, the printer automatically splits the picture onto two or more pages. The number "5" may flash on its front panel. As a possible solution to the problem, it might be necessary to either cut and paste or to rework the application to produce a less complex picture.

Program limitations with a LA100 printer:

• The picture is always printed in portrait mode.
• The scale is ignored.
• The scale factor will be different in the horizontal and vertical directions.

Program limitations with an HP printer:

• If the -density option is not specified, 300 dots-per-inch (dpi) is assumed for the ljet device and 90-dpi for the pjet device. The LaserJet printer supports 300-, 150-, 100-, and 75-dpi. Consult the operator's manual to determine the densities supported by other printers.
• If the -scale option is not specified, the image is expanded to fit the printable page area.
• The default printable page area is 8x10.5 inches. Other paper sizes can be accommodated using the -height and -width options.
• Note that a 1024x768 image fits the default printable area when processed at 100-dpi with scale=1; the same image can also be printed using 300-dpi with scale=3, but it requires more data to be transferred to the printer.
• The xpr program may be tailored for use with monochrome PCL printers other than the LaserJet. To print on a ThinkJet (HP 2225A) printer, invoke xpr as follows:

  xpr -density 96 -width 6.667 filename

  To print black-and-white output on a PaintJet printer, invoke xpr as follows:

  xpr -density 180 filename

• The monochrome intensity of a pixel is computed as 0.30*R + 0.59*G + 0.11*B. If the computed intensity of a pixel is less than the -cutoff level, it prints white. This maps light-on-dark display images to black-on-white hard copy. The default cutoff intensity is 50% of full brightness. For example, specifying -cutoff 87.5 means that a pixel will be displayed as black if the computed intensity is less than 85% of full brightness.
• A LaserJet printer must be configured with sufficient memory to print the image. To print a full page at 300-dpi, approximately 2 MB of printer memory is required.
• Color images are produced on the PaintJet printer at 90-dpi. The PaintJet is limited to 16 colors from its 330 color palette on each horizontal print line. The xpr program issues a warning message if more than 16 colors are encountered on a line. Xpr programs the PaintJet for the first 16 colors encountered on each line and uses the nearest matching programmed value for other colors on the line.
• Specifying the -rv option on the PaintJet printer causes black and white to be interchanged on the output image. No other colors are changed.
• Multiplane images must be recorded by xwd in ZPixmap format. Single-plane (monochrome) images may be in either XYPixmap or ZPixmap format.
• Some PCL printers do not recognize image positioning commands. Output for these printers is not centered on the page, and header and trailer strings may not appear where expected.
• The -gamma and -render options are supported only on the PaintJet XL printers.
• The -slide option is not supported on LaserJet printers.
• The -split option is not supported on HP printers.
• The -gray option is not supported on HP or IBM printers.

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

V1.0

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:

• DECW$GET_IMAGE_VERSION.COM
  A command procedure that extracts the image identification string from an image and places it into a user-defined symbol.
• DECW$COMPARE_VERSIONS.COM
  A command procedure that compares two image identification strings and assigns a value to a user-defined symbol with these possible results:
  • Facility codes do not match.
  • Identifiers are the same.
  • Second identifier is older than the first.
  • Second identifier is newer then the first.
• DECW$VERSIONS.COM
  A command procedure used to display the versions of several components of the DECwindows Motif layered product and the X11 display server. The DECW$VERSIONS.COM procedure uses the DECW$GET_IMAGE_VERSION.COM command procedure to obtain the image idents of each file.

  
  Use the following command to display the versions on sys$output:

  $ @SYS$UPDATE:DECW$VERSIONS *

  Component	Description
  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

  
  The output from the command procedure shows DW, the version number, and the date the image is created.
  For example:

  DW V1.2-4960312

  
  is version 1.2-4 and was created on March 12, 1996.

This section describes features related to tuning and customizing the DECwindows Motif environment.

3.2.1 Setting the File Manager Refresh Rate

V1.2--6

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 search lists.

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

V1.3

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:

• 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 3.3.1.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 3.3.1.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 3.3.1.5.

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

3.3.1.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 User-Based Access Control.
• 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 User-Based Access Control.

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.

3.3.1.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 2.6.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).

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:

• the name of the X display ([transport/][host][:]:server[.screen])
• the protocol name (MIT-MAGIC-COOKIE-1)
• a random, 128-bit numeric code known as a magic cookie

Magic Cookie access control can be implemented one of two ways depending on your DECwindows Motif system environment:

• For access control outside a DECwindows Motif session, manually create the X authority file and reference that file using the DECW$SERVER_XAUTHORITY server parameter, as described in Magic Cookie Access Control.
• For access control inside a DECwindows Motif session, use the Security Options dialog box to enable access control, as described in Magic Cookie Access Control.

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.

3.3.1.2.2 Kerberos (MIT-KERBEROS-5)

Kerberos authorizes connections to an X server based on a combination of the following:

• the protocol name (MIT-KERBEROS-5) in the X authority file
• a list of valid Kerberos principals and their associated passwords
• presentation of valid credentials

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:

• For access control outside a DECwindows Motif session, manually create the X authority file and reference that file using the DECW$SERVER_XAUTHORITY server parameter, as described in Kerberos Access Control.
• For access control inside a DECwindows Motif session, use the Security Options dialog box to enable access control and add users to the Authorized Principals list, as described in Kerberos Access Control.

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.

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:

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.

The Access Allowed File

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 Trusted File

Not to be confused with trusted network connections, as described in Section 2.6.2.7, 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.

Format of File Entries

Depending on the access control method in place, the format of file entries can differ.

• For User-Based or Magic Cookie Access Control: Each entry in an access allowed or access trusted file follows the transport-host-username format currently used by the DECwindows Motif security options, as described in Using DECwindows Motif for OpenVMS.
  For example, the following entries in an access allowed file grant user JONES local access to the server as well as network access from node ZEPHYR via 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 versus 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 or trust privileges when they connect to the X server using TCP/IP. For example, the following entry in an access allowed file grants access to all users on node ZEPHYR via the TCP/IP transport:

  TCPIP ZEPHYR * . . .

• For Kerberos Access Control: Entries are only allowed in the access allowed file. 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 via the TCP/IP transport:

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

User-Based Access Control

To apply user-based access control outside of a DECwindows Motif session, establish an access allowed and access trusted file, as follows:

1. Edit the file SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM.
2. Define the value of the DECW$SERVER_ACCESS_ALLOWED or DECW$SERVER_ACCESS_TRUSTED parameter so that it refers to the location where each file is stored, such as:

   ---

   Previous

   Next

   Contents

   Index