[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here HP DECwindows Motif for OpenVMS Alpha

HP DECwindows Motif
for OpenVMS Alpha
New Features


Previous Contents Index


$ DECW$SERVER_ACCESS_ALLOWED == "SYS$MANAGER:DECW$SERVER1_ACCESS_ALLOWED.DAT"
$ DECW$SERVER_ACCESS_TRUSTED == "SYS$MANAGER:DECW$SERVER1_ACCESS_TRUSTED.DAT"
  • Save the file.
  • Create and edit the access allowed or access trusted file adding the appropriate user entries.

    Note

    Trust privileges do not automatically grant access to the X server when using token-based authentication. If you are creating an access trusted list on a system that has either Magic Cookie or Kerberos enabled, each user on that list must also have a valid entry in the related access allowed file or X authority file in order to access the X server.
  • Save the file and restart the server. The new access or trust privileges are applied automatically at startup.

    Caution

    Authorizing TCPIP host connections to an X server using an access allowed file entry provides unauthenticated access to a DECwindows Motif system. This could leave the system vulnerable to unwanted intrusion, Denial of Service (DoS) attacks, and possible data loss.

    To ensure the proper level of system security, HP strongly recommends that a token-based scheme (such as, Magic Cookie or Kerberos) be used to authorize remote access to an X server via TCP/IP. Not only do these schemes provide greater system protection, they also allow you to grant (or deny) access on a per-user basis.

    Magic Cookie Access Control

    To apply Magic Cookie access control outside of a DECwindows Motif session, do the following:

    1. Log into the SYSTEM account or another privileged account.
    2. Edit 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, such as:


      $ DECW$SERVER_XAUTHORITY == "SYS$MANAGER:SERVER_ZEPHYR.DECW$XAUTH"
      
    3. Exit and save the file.
    4. Using 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 authorization key in this file is loaded into the X server at start up and can be used to authorize all client connections, regardless of display name.
    5. Restart the server.
    6. Propagate the key to all client systems using xauth, as described in Section 2.6.2.6.

    Kerberos Access Control

    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. Enable the TCP/IP transport by defining the DECW$SERVER_TRANSPORTS parameter in SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP and restarting the server.

    To apply Kerberos access control 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. Edit 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, such as:


      $ 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. Exit and save the file.
    5. Using 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 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"""
      
    6. 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
      
    7. 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.
    8. Restart the server.

    3.3.1.3.2 Enabling Inside a DECwindows Motif 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, authorize other users access to the X server, and specify the scheme local client applications use when connecting to an X server.

    Accessed from the Session Manager (Traditional Desktop) or Style Manager (New Desktop), the settings in Security Options dialog box are identical. Note, however, 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.

    User-Based Access Control

    To enable user-based access control and grant one or more authorized users 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, 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 your workstation.

    Magic Cookie Access Control

    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 Option 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 2.6.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.

    Note

    Any client applications that are connected to the X server when a new cookie is generated will remain connected. Authentication occurs only when initially connecting to the X server.

    Kerberos Access Control

    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. Enable the TCP/IP transport by defining the DECW$SERVER_TRANSPORT parameter 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.

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

    3.3.1.5 Using the SECURITY Extension

    Using the SECURITY extension (described in Section 4.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.

    Note

    Client applications that have not been coded to allow for their use over an untrusted connection may behave unexpectedly. See the specification for the SECURITY extension from X.Org for a description of the limitations of an untrusted connection.

    3.3.1.5.1 Enabling the SECURITY Extension

    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.

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

    3.4 Desktop Management Features

    The following sections describe features that pertain to maintaining desktop applications.

    3.4.1 Displaying Custom Messages Prior to Login

    V1.3--1

    DECwindows Motif for OpenVMS Alpha Version 1.3--1 allows system managers or other privileged users to display custom messages (such as greetings, security updates, and system broadcasts) prior to session log in.

    At session startup, DECwindows Motif searches for the message file SYS$MANAGER:DECW$GREET.TXT. If the file is found, a window that contains the text from the message file is displayed in front of the login dialog box. Users must then press the Return key or click OK to continue and log into their New Desktop session. If the file is not found, the window is not displayed, and users can log into their New Desktop session directly.

    To create a custom message, do the following:

    1. Log into SYSTEM (or another privileged account).
    2. Create the file DECW$GREET.TXT in one of the following locations:
      • For standalone systems, create the file in the directory SYS$SPECIFIC:[SYSMGR].
      • If you want to display a message across a cluster, create the file in the directory SYS$COMMON:[SYSMGR].
    3. Enter the message text that you want displayed. The text is displayed according to the font family and language variant currently defined in CDE$SYSTEM_DEFAULTS:[CONFIG]XCONFIG.DAT and CDE$SYSTEM_DEFAULTS:[CONFIG.%L]XRESOURCES.DAT. All printable characters supported by the current font family and variant are valid for display.
      Also note that there are no explicit size requirements; the message window will size itself dynamically. Extremely long lines (those that are too long to fit on the screen itself) may be truncated.

      Note

      Lines that do not contain any text or formatting characters are ignored. To insert a blank line in the message file, enter at least one space character <sp> at the beginning of the line.
    4. Save the file and restart the desktop session.

    3.4.2 Disabling the Suggested Password List

    V1.3

    You can disable the display of the suggested password list when logging into New Desktop with an expired password.

    To suppress the suggested password list, define the system logical CDE$NOGENPWD to a non-zero value, as follows:


    $  DEFINE/SYSTEM CDE$NOGENPWD 1
    

    3.4.3 Allowing Trusted Users to Unlock Paused Desktop Sessions

    V1.3

    You can now grant a DECwindows Motif user the ability to unlock a DECwindows Motif session paused using the Screen Lock function described in Section 2.3.2.

    To specify the trusted user, define the system logical DECW$TRUSTED_UNPAUSE logical, as follows, where username represents the name of an OpenVMS Alpha user:


    $  DEFINE/SYSTEM DECW$TRUSTED_UNPAUSE "username"
    

    3.4.4 Displaying an Expanded Welcome Message

    V1.2--6

    You can now enter a longer, customized welcome message to be displayed on the Login Screen of the New Desktop. The size of the welcome message string (Dtlogin*greeting.labelString) in XRESOURCES.DAT has been expanded allowing you to enter more than 8 lines of text.

    Note that the actual number of lines you can enter and display is limited by the size of the screen and the selected font. However, a minimum of 25 lines is allowed on most display devices.

    3.4.5 Displaying Console Messages

    V1.2--3

    DECwindows Motif for OpenVMS Version 1.2--3 introduced the feature of displaying console messages in the Console Window application. Previous versions of DECwindows Motif displayed the console window by default.

    Note

    The new default for displaying console messages starting with the DECwindows Motif for OpenVMS Version 1.2--3 release is DISABLE. The default in previous versions of DECwindows Motif was ENABLE. These values are discussed in greater detail later in this section. If the user selects the Alternate Console port for console communications, the DECwindows Console Window is disabled and the console broadcasts are enabled. Refer to the owner's guide for your workstation for information about selecting the Alternate Console port.

    3.4.5.1 Display Options

    Specify how to display messages by defining the global symbol DECW$CONSOLE_SELECTION in the customized startup file SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM. Enter one of the following values: WINDOW, DISABLE, or ENABLE.

    • WINDOW
      Displays console messages in the Console Window application. This is a new application starting with the DECwindows Motif for OpenVMS Version 1.2--3 software. If you specify the WINDOW value, the Console Window is displayed in the lower right corner of the login screen by default and continues to be displayed after the user logs in to the system.
      The Console Window application shares the same executable file and looks similar to the Message Window. However, a menu bar is not displayed in the Console Window; it reads its resources from the DECW$CONSOLE.DAT file instead of from the DECW$MESSAGEPANEL.DAT file. Internally, the Console Window is invoked by running the DECW$MESSAGEPANEL.EXE executable with the command line option -console.
      To control the initial position of the Console Window and the classes of OPCOM output that are enabled, you can the define the DECW$CONSOLE_GEOMETRY global symbol in the file SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM.
      The DECW$CONSOLE_GEOMETRY symbol specifies the value of the -geometry option in the DECW$MESSAGEPANEL.EXE command line; this command is used to start the Console Window application. The default value is "-0-0", which specifies the location of the window in the lower right corner of the screen.
      To position the window at the lower left corner of the screen, for example, add the following line to the command file SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM:


       $ DECW$CONSOLE_GEOMETRY == "+0-0"
      
    • DISABLE (default)
      Disables broadcasts to the OPA0: device. Console messages are not displayed.
    • ENABLE
      Displays console messages in the console window. The console window is a six-line display area at the top of the workstation screen.

      Note

      Although ENABLE was the default value in previous releases of DECwindows Motif, it is recommended that you do not use this option with DECwindows Motif for OpenVMS Version 1.2--3 and later versions. Displaying console messages by default in the console window can corrupt the contents of the workstation display.


    Previous Next Contents Index