Commands Reference, Volume 6

To specify the visual type and depth for the default visual, use the -cc and -d flags, respectively.

Values for the VisualType parameter are specified as a string or a number as follows:

String  Numeric equivalent
StaticGray		0
GrayScale		1
StaticColor		2
PseudoColor		3		
TrueColor		4
DirectColor		5	

The :Display parameter is optional, but useful when using the multihead option and must correspond to the values passed with the -P flag. The :Display parameter is the name of the display as shown in the lsdisp command. In the absence of the :Display parameter, the specified depth is selected for all the selected displays in the multihead option, as specified in the -P flag.

Value           Setting
0               Off
1-33            Low
-1 or 34-66     Medium
67-100          High

X -n :18

specifies that communication to the activated X server takes place by unix:18 or by Hostname:18.

The Display parameter is the device name of the display as shown in the first column of output from the Isdisp command. The first -PRowColumn Display occurrence on the command line describes screen 0 to the X server, the second describes screen 1, and so on.

The -P flag is for use with multiple head support.

The level parameter indicates the relative amount of frame buffer memory to be reserved for pbuffers. Specified values must be in the range of [0..2]. A value of 0 indicates that no memory should be reserved for pbuffers. A value of 1 indicates that a low amount of memory should be reserved. A value of 2 indicates that a high amount of memory should be reserved. Not all adapters support pbuffers. For those that do, not all screen configurations support pbuffers. The actual amount of frame buffer memory reserved for pbuffers is device-dependent, and may be influenced by other factors, such as screen resolution or default pixel depth.

The :display parameter is optional, but useful when using the multihead option. The :display parameter is the name of the display as shown in the lsdisp command. If no display number or name is supplied, the specified pbuffer width is selected for all screens.

Supported screens will configure the adapter to provide the best available support for stereo. This may decrease other resources such as texture memory. The actual amount of memory affected is device-dependent, and may be influenced by other factors, such as screen resolution or default pixel depth.

The Display parameter is optional, but useful when using the multihead option. The Display parameter is the name of the display as shown in the lsdisp command. If no display number or name is supplied, the -stereo flag pertains to all supported screens.

Unsupported screens will ignore the -stereo flag.

Conversely, if this flag is set and the hotspot of the mouse reaches the right border of the rightmost root window, the mouse is automatically positioned at the left border of the leftmost root window at the same y position. If this flag is not set, the mouse stops at the left or right border of any root window.

If this flag is set and the hotspot of the mouse reaches the top border of the topmost root window, the mouse is positioned at the bottom border of the bottommost root window at the same x position.

Conversely, if this flag is set and the hotspot of the mouse reaches the bottom border of the bottommost root window, the mouse is positioned at the top border of the topmost root window at the same x position.

The -wrap flag is for use with multiple head support.

The -wrapx flag is for use with multiple head support.

Conversely, if this flag is set and the hotspot of the mouse reaches the bottom border of the bottommost root window, the mouse is positioned at the top border of the topmost root window at the same x position. If this flag is not set, the mouse stops at the top or bottom border of any root window.

The -wrapy flag is for use with multiple head support.

The -query flag is for use with XDMCP.

The -broadcast flag is for use with XDMCP.

The -indirect flag is for use with XDMCP.

The -port flag is for use with XDMCP.

The -class flag is for use with XDMCP.

The -cookie flag is for use with XDMCP.

The -displayID flag is for use with XDMCP.

The syntax of the security policy file is as follows. Notation: "*" means zero or more occurrences of the preceding element, and "+" means one or more occurrences. To interpret foo/bar, ignore the text after the /; it is used to distinguish between instances of foo in the next section.

policy file ::= version line other line*
version line ::= string/v '\n'
other line  ::= comment | access rule | site policy | blank line
comment ::= # not newline* '\n'
blank line ::= space '\n'
site policy ::= sitepolicy string/sp '\n'
access rule ::= property property/ar window perms '\n'
property ::= string
window ::= any | root | required property
required property ::= property/rp | property with value
property with value ::= property/rpv = string/rv
perms ::= [ operation | action | space ]*
operation ::= r | w | d
action ::= a | i | e
string ::= dbl quoted string | single quoted string | unqouted string
dbl quoted string ::= space " not dqoute* " space
single quoted string ::= space ' not squote* ' space
unquoted string ::= space not space+ space
space ::= [ ' ' | '\t' ]*

Character sets:

not newline ::= any character except '\n'
not dqoute  ::= any character except "
not squote  ::= any character except '
not space   ::= any character except those in space

The semantics associated with the previously described syntax are as follows.

version line

The first line in the file, specifies the file format version. If the server does not recognize the version string/v, it ignores the rest of the file. The version string for the file format described here is version-1.

Once past the version line, lines that do not match the above syntax are ignored.

comment

Lines are ignored.

sitepolicy

Lines are currently ignored. They are intended to specify the site policies used by the XC-QUERY-SECURITY-1 authorization method.

access rule

Lines specify how the server should react to untrusted client requests that affect the X Window property named property/ar. The rest of this section describes the interpretation of an access rule.

For an access rule to apply to a given instance of property/ar, property/ar must be on a window that is in the set of windows specified by window. If window is any, the rule applies to property/ar on any window. If window is root, the rule applies to property/ar only on root windows.

If window is required property, the following apply. If required property is a property/rp, the rule applies when the window also has that property/rp, regardless of its value. If required property is a property with value, property/rpv must also have the value specified by string/rv. In this case, the property must have type STRING and format 8, and should contain one or more null- terminated strings. If any of the strings match string/rv, the rule applies.

The definition of string matching is simple case-sensitive string comparison with one elaboration: the occurrence of the character '*' in string/rv is a wildcard meaning "any string." A string/rv can contain multiple wildcards anywhere in the string. For example, x* matches strings that begin with x, *x matches strings that end with x, *x* matches strings containing x, and x*y* matches strings that start with x and subsequently contain y.

There may be multiple access rule lines for a given property/ar. The rules are tested in the order that they appear in the file. The first rule that applies is used.

perms

Specify operations that untrusted clients may attempt, and the actions that the server should take in response to those operations.

operation

Can be r (read), w (write), or d (delete). The following information shows how X Protocol property requests map to these operations in the X Consortium server implementation.

GetProperty

r, or r and d if delete = True

ChangeProperty

w

RotateProperties

r and w

DeleteProperty

d

ListProperties

none, untrusted clients can always list all properties

action

Can be a (allow), i (ignore), or e (error).

Allow

Executes the request as if it had been issued by a trusted client.

Ignore

Treats the request as a no-op. In the case of GetProperty, ignore means return an empty property value if the property exists, regardless of its actual value.

Error

Specifies not to execute the request and return a BadAtom error with the atom set to the property name. Error is the default action for all properties, including those not listed in the security policy file.

An action applies to all operations that follow it, until the next action> is encountered. Thus, irwad means ignore read and write, allow delete.

GetProperty and RotateProperties might do multiple operations (r and d, or r and w). If different actions apply to the operations, the most severe action is applied to the whole request; there is no partial request execution. The severity ordering is: allow < ignore < error. Thus, if the perms for a property are ired (ignore read, error delete), and an untrusted client attempts GetProperty on that property with delete = True, an error is returned, but the property value is not. Similarly, if any of the properties in a RotateProperties do not allow both read and write, an error is returned without changing any property values.

An example a security policy file follows:

version-1

# Allow reading of application resources, but not writing.
property RESOURCE_MANAGER     root      ar iw
property SCREEN_RESOURCES     root      ar iw

# Ignore attempts to use cut buffers.  Giving errors causes apps to crash,
# and allowing access may give away too much information.
property CUT_BUFFER0          root      irw
property CUT_BUFFER1          root      irw
property CUT_BUFFER2          root      irw
property CUT_BUFFER3          root      irw
property CUT_BUFFER4          root      irw
property CUT_BUFFER5          root      irw
property CUT_BUFFER6          root      irw
property CUT_BUFFER7          root      irw

# If you are using Motif, you probably want these.

property _MOTIF_DEFAULT_BINDINGS        rootar iw
property _MOTIF_DRAG_WINDOW   root      ar iw
property _MOTIF_DRAG_TARGETS  any       ar iw
property _MOTIF_DRAG_ATOMS    any       ar iw
property _MOTIF_DRAG_ATOM_PAIRS         any ar iw

# The next two rules let xwininfo -tree work when untrusted.
property WM_NAME              any       ar

# Allow read of WM_CLASS, but only for windows with WM_NAME.
# This might be more restrictive than necessary, but demonstrates
# the required property facility, and is also an attempt to
# say "top level windows only."
property WM_CLASS             WM_NAME   ar

# These next three let xlsclients work untrusted.  Think carefully
# before including these; giving away the client machine name and command
# may be exposing too much.
property WM_STATE             WM_NAME   ar
property WM_CLIENT_MACHINE    WM_NAME   ar
property WM_COMMAND           WM_NAME   ar

# To let untrusted clients use the standard colormaps created by
# xstdcmap, include these lines.
property RGB_DEFAULT_MAP      root      ar
property RGB_BEST_MAP         root      ar
property RGB_RED_MAP          root      ar
property RGB_GREEN_MAP        root      ar
property RGB_BLUE_MAP         root      ar
property RGB_GRAY_MAP         root      ar

# To let untrusted clients use the color management database created
# by xcmsdb, include these lines.
property XDCCC_LINEAR_RGB_CORRECTION    rootar
property XDCCC_LINEAR_RGB_MATRICES      rootar
property XDCCC_GRAY_SCREENWHITEPOINT    rootar
property XDCCC_GRAY_CORRECTION          rootar


# oddball property names and explicit specification of error conditions
property "property with spaces"         'property with "'aw er ed

# Allow deletion of Woo-Hoo if window also has property OhBoy with value
# ending in "son".  Reads and writes will cause an error.
property Woo-Hoo              OhBoy = "*son"ad