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:

   XDPSCreateSecureContext
   
   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
   
   space;

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.