JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Solaris X Window System Developer's Guide
search filter icon
search icon

Document Information


1.  Introduction to the Solaris X Server

2.  DPS Features and Enhancements

About DPS

How DPS Works

DPS Font Enhancements in the Solaris Server

DPS Libraries

Adobe NX Agent Support

DPS Security Issues

System File Access

Secure Context Creation

When DPS Encounters Internal Errors

How To Access Information From Adobe

DPS Compositing Operators

Operator Descriptions

Implementation Notes and Limitations

Partially Transparent Alpha

Indexed Color Visuals

Monochrome Displays

Interaction with X Drawing Operations

Destroying the Alpha Channel

Drawables with Unequal Depths

3.  Visuals on the Solaris X Server

4.  Font Support

5.  Server Overlay Windows

6.  Transparent Overlay Windows

7.  Security Issues

A.  Reference Display Devices



DPS Security Issues

The Solaris environment provides, and in some cases exceeds, the X Consortium's X11R5 sample server security levels. In particular, DPS programmers should be aware of two DPS-specific security features: PostScript file operators' inability to access system files, and secure context creation. These features are described below.

System File Access

The PostScript language provides file operations that allow users to access system devices such as disk files. This presents a serious security problem. In the Solaris environment, you cannot—by default—use PostScript file operators to open or otherwise access a system file.

For applications, the client rather than the server should perform necessary file operations. Thus, the client does not need all the same access privileges that the server needs. If you want PostScript file operators to access system files, start the server with the -dpsfileops option (see the Xsun(1) man page). If you attempt to access system files without specifying -dpsfileops, you will get a PostScript undefinedfilename error. This issue is particularly important in the CDE or xdm environment, as the server process is owned by a super-user.

Secure Context Creation

DPS contexts normally have access to global data. This allows a context to look into the activities of another context. For example, one context could intercept a document that another context is imaging. This section describes how to create secure contexts in the Solaris environment.

Section 7.1.1 “Creating Contexts” in the PostScript Language Reference Manual, Second Edition describes three ways that contexts can share VM:

  1. “Local and global VM are completely private to the context.” This capability is new with Level 2, and a context created this way is called a secure context.

  2. “Local VM is private to the context, but global VM is shared with some other context.” This is the normal situation for contexts created with XDPSCreateContext and XDPSCreateSimpleContext.

  3. “Local and global VM are shared with some other context.” This is the situation for contexts created with XDPSCreateContext and XDPSCreateSimpleContext when the space parameter is not NULL.

    To create a secure context, use XDPSCreateSecureContext as shown below:

    DPSContext XDPSCreateSecureContext(dpy,    drawable, gc, x, y, eventmask,
    grayramp, ccube, actual,     textProc, errorProc, space)  Display *dpy;
      Drawable drawable;  GC gc;  int x;  int y;  unsigned int eventmask;
      XStandardColormap *grayramp;  XStandardColormap *ccube;  int actual;
      DPSTextProc textProc;  DPSErrorProc errorProc;   DPSSpace

All parameters have the identical meaning to those in XDPSCreateContext, but the context being created has its own private global VM. If the space parameter is not NULL, it must identify a space created with a secure context. A space created with a secure context cannot be used for the creation of a nonsecure context. Specifying a nonsecure space with a secure context or a secure space with a nonsecure context generates an access error.