Gecko [ www.foryou-vip.com ]

Name	Size	Permission	Date
appgrp.html	49.82 KB	-rw-r--r--	2014-01-06 10:39
appgrp.txt.gz	7.08 KB	-rw-r--r--	2014-01-06 10:39
changelog.Debian.gz	2.23 KB	-rw-r--r--	2014-01-06 10:39
copyright	10.06 KB	-rw-r--r--	2014-01-06 10:39
dbe.html	47.71 KB	-rw-r--r--	2014-01-06 10:39
dbe.txt.gz	8.02 KB	-rw-r--r--	2014-01-06 10:39
dpms.html	27 KB	-rw-r--r--	2014-01-06 10:39
dpms.txt.gz	3.76 KB	-rw-r--r--	2014-01-06 10:39
evi.html	23.45 KB	-rw-r--r--	2014-01-06 10:39
evi.txt.gz	3.22 KB	-rw-r--r--	2014-01-06 10:39
geproto.html	14.4 KB	-rw-r--r--	2014-01-06 10:39
geproto.txt.gz	1.86 KB	-rw-r--r--	2014-01-06 10:39
lbx.html	172.9 KB	-rw-r--r--	2014-01-06 10:39
lbx.txt.gz	23.22 KB	-rw-r--r--	2014-01-06 10:39
multibuf.html	62.89 KB	-rw-r--r--	2014-01-06 10:39
multibuf.txt.gz	11.25 KB	-rw-r--r--	2014-01-06 10:39
security.html	58.59 KB	-rw-r--r--	2014-01-06 10:39
security.txt.gz	9.6 KB	-rw-r--r--	2014-01-06 10:39
shape.html	46.25 KB	-rw-r--r--	2014-01-06 10:39
shape.txt.gz	6.4 KB	-rw-r--r--	2014-01-06 10:39
shm.html	25.95 KB	-rw-r--r--	2014-01-06 10:39
shm.txt.gz	4.9 KB	-rw-r--r--	2014-01-06 10:39
sync.html	58.78 KB	-rw-r--r--	2014-01-06 10:39
sync.txt.gz	9.84 KB	-rw-r--r--	2014-01-06 10:39
tog-cup.html	25.94 KB	-rw-r--r--	2014-01-06 10:39
tog-cup.txt.gz	3.92 KB	-rw-r--r--	2014-01-06 10:39
xtest.html	28.98 KB	-rw-r--r--	2014-01-06 10:39
xtest.txt.gz	4.52 KB	-rw-r--r--	2014-01-06 10:39

Rename

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Security Extension Specification</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1" /><style xmlns="" type="text/css">/*
 * Copyright (c) 2011 Gaetan Nadon
 * Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and associated documentation files (the "Software"),
 * to deal in the Software without restriction, including without limitation
 * the rights to use, copy, modify, merge, publish, distribute, sublicense,
 * and/or sell copies of the Software, and to permit persons to whom the
 * Software is furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice (including the next
 * paragraph) shall be included in all copies or substantial portions of the
 * Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
 * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 * DEALINGS IN THE SOFTWARE.
 */

/*
 * Shared stylesheet for X.Org documentation translated to HTML format
 * http://www.sagehill.net/docbookxsl/UsingCSS.html
 * http://www.w3schools.com/css/default.asp
 * https://addons.mozilla.org/en-US/firefox/addon/web-developer/developers
 * https://addons.mozilla.org/en-US/firefox/addon/font-finder/
 */

/*
 * The sans-serif fonts are considered more legible on a computer screen
 * http://dry.sailingissues.com/linux-equivalents-verdana-arial.html
 *
 */
body {
  font-family: "Bitstream Vera Sans", "DejaVu Sans", Tahoma, Geneva, Arial, Sans-serif;
  /* In support of using "em" font size unit, the w3c recommended method */
  font-size: 100%;
}

/*
 * Selection: all elements requiring mono spaced fonts.
 *
 * The family names attempt to match the proportionally spaced font
 * family names such that the same font name is used for both.
 * We'd like to use Bitstream, for example, in both proportionally and
 * mono spaced font text.
 */
.command,
.errorcode,
.errorname,
.errortype,
.filename,
.funcsynopsis,
.function,
.parameter,
.programlisting,
.property,
.screen,
.structname,
.symbol,
.synopsis,
.type
{
  font-family:  "Bitstream Vera Sans Mono", "DejaVu Sans Mono", Courier, "Liberation Mono", Monospace;
}

/*
 * Books have a title page, a preface, some chapters and appendices,
 * a glossary, an index and a bibliography, in that order.
 *
 * An Article has no preface and no chapters. It has sections, appendices,
 * a glossary, an index and a bibliography.
 */

/*
 * Selection: book main title and subtitle
 */
div.book>div.titlepage h1.title,
div.book>div.titlepage h2.subtitle {
  text-align: center;
}

/*
 * Selection: article main title and subtitle
 */
div.article>div.titlepage h2.title,
div.article>div.titlepage h3.subtitle,
div.article>div.sect1>div.titlepage h2.title,
div.article>div.section>div.titlepage h2.title {
  text-align: center;
}

/*
 * Selection: various types of authors and collaborators, individuals or corporate
 *
 * These authors are not always contained inside an authorgroup.
 * They can be contained inside a lot of different parent types where they might
 * not be centered.
 * Reducing the margin at the bottom makes a visual separation between authors
 * We specify here the ones on the title page, others may be added based on merit.
 */
div.titlepage .authorgroup,
div.titlepage .author,
div.titlepage .collab,
div.titlepage .corpauthor,
div.titlepage .corpcredit,
div.titlepage .editor,
div.titlepage .othercredit {
  text-align: center;
  margin-bottom: 0.25em;
}

/*
 * Selection: the affiliation of various types of authors and collaborators,
 * individuals or corporate.
 */
div.titlepage .affiliation {
  text-align: center;
}

/*
 * Selection: product release information (X Version 11, Release 7)
 *
 * The releaseinfo element can be contained inside a lot of different parent
 * types where it might not be centered.
 * We specify here the one on the title page, others may be added based on merit.
 */
div.titlepage p.releaseinfo {
  font-weight: bold;
  text-align: center;
}

/*
 * Selection: publishing date
 */
div.titlepage .pubdate {
  text-align: center;
}

/*
 * The legal notices are displayed in smaller sized fonts
 * Justification is only supported in IE and therefore not requested.
 *
 */
.legalnotice {
  font-size: small;
  font-style: italic;
}

/*
 * For documentation having multiple licenses, the copyright and legalnotice
 * elements sequence cannot instantiated multiple times.
 * The copyright notice and license text are therefore coded inside a legalnotice
 * element. The role attribute on the paragraph is used to allow styling of the
 * copyright notice text which should not be italicized.
 */
p.multiLicensing {
  font-style: normal;
  font-size: medium;
}

/*
 * Selection: book or article main ToC title
 * A paragraph is generated for the title rather than a level 2 heading.
 * We do not want to select chapters sub table of contents, only the main one
 */
div.book>div.toc>p,
div.article>div.toc>p {
  font-size: 1.5em;
  text-align: center;
}

/*
 * Selection: major sections of a book or an article
 *
 * Unlike books, articles do not have a titlepage element for appendix.
 * Using the selector "div.titlepage h2.title" would be too general.
 */
div.book>div.preface>div.titlepage h2.title,
div.book>div.chapter>div.titlepage h2.title,
div.article>div.sect1>div.titlepage h2.title,
div.article>div.section>div.titlepage h2.title,
div.book>div.appendix>div.titlepage h2.title,
div.article>div.appendix h2.title,
div.glossary>div.titlepage h2.title,
div.index>div.titlepage h2.title,
div.bibliography>div.titlepage h2.title {
   /* Add a border top over the major parts, just like printed books */
   /* The Gray color is already used for the ruler over the main ToC. */
  border-top-style: solid;
  border-top-width: 2px;
  border-top-color: Gray;
  /* Put some space between the border and the title */
  padding-top: 0.2em;
  text-align: center;
}

/*
 * A Screen is a verbatim environment for displaying text that the user might
 * see on a computer terminal. It is often used to display the results of a command.
 *
 * http://www.css3.info/preview/rounded-border/
 */
.screen {
  background: #e0ffff;
  border-width: 1px;
  border-style: solid;
  border-color: #B0C4DE;
  border-radius: 1.0em;
  /* Browser's vendor properties prior to CSS 3 */
  -moz-border-radius: 1.0em;
  -webkit-border-radius: 1.0em;
  -khtml-border-radius: 1.0em;
  margin-left: 1.0em;
  margin-right: 1.0em;
  padding: 0.5em;
}

/*
 * Emphasis program listings with a light shade of gray similar to what
 * DocBook XSL guide does: http://www.sagehill.net/docbookxsl/ProgramListings.html
 * Found many C API docs on the web using like shades of gray.
 */
.programlisting {
  background: #F4F4F4;
  border-width: 1px;
  border-style: solid;
  border-color: Gray;
  padding: 0.5em;
}

/*
 * Emphasis functions synopsis using a darker shade of gray.
 * Add a border such that it stands out more.
 * Set the padding so the text does not touch the border.
 */
.funcsynopsis, .synopsis {
  background: #e6e6fa;
  border-width: 1px;
  border-style: solid;
  border-color: Gray;
  clear: both;
  margin: 0.5em;
  padding: 0.25em;
}

/*
 * Selection: paragraphs inside synopsis
 *
 * Removes the default browser margin, let the container set the padding.
 * Paragraphs are not always used in synopsis
 */
.funcsynopsis p,
.synopsis p {
  margin: 0;
  padding: 0;
}

/*
 * Selection: variable lists, informal tables and tables
 *
 * Note the parameter name "variablelist.as.table" in xorg-xhtml.xsl
 * A table with rows and columns is constructed inside div.variablelist
 *
 * Set the left margin so it is indented to the right
 * Display informal tables with single line borders
 */
table {
  margin-left: 0.5em;
  border-collapse: collapse;
}

/*
 * Selection: paragraphs inside tables
 *
 * Removes the default browser margin, let the container set the padding.
 * Paragraphs are not always used in tables
 */
td p {
  margin: 0;
  padding: 0;
}

/*
 * Add some space between the left and right column.
 * The vertical alignment helps the reader associate a term
 * with a multi-line definition.
 */
td, th {
  padding-left: 1.0em;
  padding-right: 1.0em;
  vertical-align: top;
}

.warning {
  border: 1px solid red;
  background: #FFFF66;
  padding-left: 0.5em;
}
</style></head><body><div class="book"><div class="titlepage"><div><div><h1 class="title"><a id="security"></a>Security Extension Specification</h1></div><div><h2 class="subtitle">X Consortium Standard</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">David</span> <span class="othername">P.</span> <span class="surname">Wiggins</span></h3><div class="affiliation"><span class="orgname">X Consortium<br /></span></div></div></div></div><div><p class="releaseinfo">X Version 11, Release 7.7</p></div><div><p class="releaseinfo">Version 7.1</p></div><div><p class="copyright">Copyright © 1996 X Consortium</p></div><div><div class="legalnotice"><a id="idp51985312"></a><p>
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the “Software”), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
</p><p>
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
</p><p>
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
</p><p>
Except as contained in this notice, the name of the X Consortium shall not be
used in advertising or otherwise to promote the sale, use or other dealings
in this Software without prior written authorization from the X Consortium.
</p><p>X Window System is a trademark of The OpenGroup.</p></div></div><div><p class="pubdate">November 15, 1996</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="chapter"><a href="#Introduction">1. Introduction</a></span></dt><dt><span class="chapter"><a href="#Requests">2. Requests</a></span></dt><dd><dl><dt><span class="sect1"><a href="#SecurityQueryVersion">SecurityQueryVersion</a></span></dt><dt><span class="sect1"><a href="#SecurityGenerateAuthorization">SecurityGenerateAuthorization</a></span></dt><dt><span class="sect1"><a href="#SecurityRevokeAuthorization">SecurityRevokeAuthorization</a></span></dt></dl></dd><dt><span class="chapter"><a href="#Changes_to_Core_Requests">3. Changes to Core Requests</a></span></dt><dd><dl><dt><span class="sect1"><a href="#Resource_ID_Usage">Resource ID Usage</a></span></dt><dt><span class="sect1"><a href="#Extension_Security">Extension Security</a></span></dt><dt><span class="sect1"><a href="#Keyboard_Security">Keyboard Security</a></span></dt><dt><span class="sect1"><a href="#Image_Security">Image Security</a></span></dt><dt><span class="sect1"><a href="#Property_Security">Property Security</a></span></dt><dt><span class="sect1"><a href="#Miscellaneous_Security">Miscellaneous Security</a></span></dt></dl></dd><dt><span class="chapter"><a href="#New_Authorization_Method">4. New Authorization Method</a></span></dt><dt><span class="chapter"><a href="#Encoding">5. Encoding</a></span></dt><dd><dl><dt><span class="sect1"><a href="#Types">Types</a></span></dt><dt><span class="sect1"><a href="#Request_Encoding">Request Encoding</a></span></dt><dt><span class="sect1"><a href="#Event_Encoding">Event Encoding</a></span></dt><dt><span class="sect1"><a href="#Authorization_Method_Encoding">Authorization Method Encoding</a></span></dt></dl></dd><dt><span class="chapter"><a href="#C_Language_Binding">6. C Language Binding</a></span></dt></dl></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="Introduction"></a>Chapter 1. Introduction</h1></div></div></div><p>
The Security extension contains new protocol needed to provide enhanced X
server security. The Security extension should not be exposed to untrusted
clients (defined below).
</p></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="Requests"></a>Chapter 2. Requests</h1></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#SecurityQueryVersion">SecurityQueryVersion</a></span></dt><dt><span class="sect1"><a href="#SecurityGenerateAuthorization">SecurityGenerateAuthorization</a></span></dt><dt><span class="sect1"><a href="#SecurityRevokeAuthorization">SecurityRevokeAuthorization</a></span></dt></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="SecurityQueryVersion"></a>SecurityQueryVersion</h2></div></div></div><p>
This request returns the major and minor version numbers of this extension.
</p><p>SecurityQueryVersion</p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /></colgroup><tbody><tr><td align="left">
          <p>client-major-version</p>
        </td><td align="left">
          <p>CARD16</p>
        </td></tr><tr><td align="left">
          <p>client-minor-version</p>
        </td><td align="left">
          <p>CARD16</p>
        </td></tr><tr><td align="left">
          <p>=&gt;</p>
        </td><td class="auto-generated"> </td></tr><tr><td align="left">
          <p>server-major-version</p>
        </td><td align="left">
          <p>CARD16</p>
        </td></tr><tr><td align="left">
          <p>server-minor-version</p>
        </td><td align="left">
          <p>CARD16</p>
        </td></tr></tbody></table></div><p>
The client-major-version and client-minor-version numbers indicate what
version of the protocol the client wants the server to implement. The
server-major-version and the server-minor-version numbers returned
indicate the protocol this extension actually supports. This might not
equal the version sent by the client. An implementation can (but need not)
support more than one version simultaneously.  The server-major-version
and server-minor-version allow the creation of future revisions of the
Security protocol that may be necessary. In general, the major version
would increment for incompatible changes, and the minor version would
increment for small, upward-compatible changes. Servers that support
the protocol defined in this document will return a server-major-version
of one (1), and a server-minor-version of zero (0).
</p><p>
Clients using the Security extension must issue a SecurityQueryVersion
request before any other Security request in order to negotiate a compatible
protocol version; otherwise, the client will get undefined behavior
(Security may or may not work).
</p></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="SecurityGenerateAuthorization"></a>SecurityGenerateAuthorization</h2></div></div></div><p>
This request causes the server to create and return a new authorization with
specific characteristics. Clients can subsequently connect using the new
authorization and will inherit some of the characteristics of the
authorization.
</p><p>
SecurityGenerateAuthorization
</p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /></colgroup><tbody><tr><td align="left">
          <p>authorization-protocol-name</p>
        </td><td align="left">
          <p>STRING8</p>
        </td></tr><tr><td align="left">
          <p>authorization-protocol-data</p>
        </td><td align="left">
          <p>STRING8</p>
        </td></tr><tr><td align="left">
          <p>value-mask</p>
        </td><td align="left">
          <p>BITMASK</p>
        </td></tr><tr><td align="left">
          <p>value-list</p>
        </td><td align="left">
          <p>LISTofVALUE</p>
        </td></tr><tr><td align="left">
          <p>=&gt;</p>
        </td><td align="left">
        </td></tr><tr><td align="left">
          <p>authorization-id</p>
        </td><td align="left">
          <p>AUTHID</p>
        </td></tr><tr><td align="left">
          <p>authorization-data-return</p>
        </td><td align="left">
          <p>STRING8</p>
        </td></tr></tbody></table></div><p>
Errors: <code class="function">AuthorizationProtocol</code>, <code class="function">Value</code>, <code class="function">Alloc</code>
</p><p>
authorization-protocol-name is the name of the authorization method for
which the server should generate a new authorization that subsequent
clients can use to connect to the server. If the authorization-protocol-name
is not one that the server supports, or if authorization-protocol-data
does not make sense for the given authorization-protocol-name, an
AuthorizationProtocol error results.
</p><p>
authorization-protocol-data is authorization-method specific data that can
be used in some way to generate the authorization.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
In this version of the extension, the only authorization method
required to be supported is "MIT-MAGIC-COOKIE-1" with any amount
of authorization-protocol-data (including none). The server may use the
authorization-protocol-data as an additional source of randomness used
to generate the authorization. Other authorization methods can supply
their own interpretation of authorization-protocol-data.
</p></div><p>
The value-mask and value-list specify attributes of the authorization
that are to be explicitly initialized. The possible values are:
</p><div class="informaltable"><table border="1"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /><col align="left" class="c3" /></colgroup><thead><tr><th align="left">Attribute</th><th align="left">Type</th><th align="left">Default</th></tr></thead><tbody><tr><td align="left">
          <p>timeout</p>
        </td><td align="left">
          <p>CARD32</p>
        </td><td align="left">
          <p>60</p>
        </td></tr><tr><td align="left">
          <p>group</p>
        </td><td align="left">
          <p>XID or None</p>
        </td><td align="left">
          <p>None</p>
        </td></tr><tr><td align="left">
          <p>trust-level</p>
        </td><td align="left">
          <p>{SecurityClientTrusted,</p>
        </td><td class="auto-generated"> </td></tr><tr><td align="left">
          <p></p>
        </td><td align="left">
          <p>SecurityClientUntrusted}</p>
        </td><td align="left">
          <p>SecurityClientUntrusted</p>
        </td></tr><tr><td align="left">
          <p>event-mask</p>
        </td><td align="left">
          <p>SecurityAuthorizationRevoked,</p>
        </td><td class="auto-generated"> </td></tr><tr><td align="left">
          <p></p>
        </td><td align="left">
          <p>or None</p>
        </td><td align="left">
          <p>None</p>
        </td></tr></tbody></table></div><p>
timeout is the timeout period in seconds for this authorization. A
timeout value of zero means this authorization will never expire. For
non-zero timeout values, when timeout seconds have elapsed since the
last time that the authorization entered the state of having no
connections authorized by it, and if no new connections used the
authorization during that time, the authorization is automatically purged.
(Note that when an authorization is created, it enters the state of having no
connections authorized by it.) Subsequent connection attempts using that
authorization will fail. This is to facilitate "fire and forget" launching of
applications.
</p><p>
group is an application group ID as defined by the Application Group
extension, or None. Any other values will cause a Value error. When a
group is destroyed, all authorizations specifying that group are revoked
as described under the SecurityRevokeAuthorization request. The Application
Group extension attaches additional semantics to the group.
</p><p>
trust-level tells whether clients using the authorization are trusted or
untrusted. If trust-level is not one of the constants SecurityClientTrusted
or SecurityClientUntrusted, a Value error results.
</p><p>
event-mask defines which events the client is interested in for this
authorization.  When the authorization expires or is revoked if event-mask
contains SecurityAuthorizationRevoked a SecurityAuthorizationRevoked event
is reported to the client.
</p><p>
The SecurityAuthorizationRevoked event contains the following field:
</p><div class="informaltable"><table border="1"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /></colgroup><thead><tr><th align="left">Field</th><th align="left">Type</th></tr></thead><tbody><tr><td align="left">
          <p>authorization-id</p>
        </td><td align="left">
          <p>AUTHID</p>
        </td></tr></tbody></table></div><p>
where authorization-id is the identification of the authorization that was
revoked.
</p><p>
If an invalid value-mask is specified, a Value error occurs.
</p><p>
The returned authorization-id is a non-zero value that uniquely identifies
this authorization for use in other requests. The value space for type
AUTHID is not required to be disjoint from values spaces of other core
X types, e.g. resource ids, atoms, visual ids, and keysyms. Thus, a given
numeric value might be both a valid AUTHID and a valid atom, for example.
</p><p>
authorization-data-return is the data that a client should use in some
authorization-method-specific way to make a connection with this
authorization. For "MIT-MAGIC-COOKIE-1," authorization-data-return should
be sent as the authorization-protocol-data in the connection setup message.
It is not required that other authorization methods use
authorization-data-return this way.
</p></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="SecurityRevokeAuthorization"></a>SecurityRevokeAuthorization</h2></div></div></div><p>
This request deletes an authorization created by SecurityGenerateAuthorization.
</p><p>
SecurityRevokeAuthorization
</p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /></colgroup><tbody><tr><td align="left">
          <p><span class="emphasis"><em>authorization-id</em></span></p>
        </td><td align="left">
          <p>AUTHID</p>
        </td></tr></tbody></table></div><p>
Errors: <code class="function">Authorization</code>
</p><p>
If authorization-id does not name a valid authorization, an Authorization
error occurs. Otherwise, this request kills all clients currently connected
using the authorization specified by authorization-id. The authorization is
deleted from the server's database, so future attempts by clients to connect
with this authorization will fail.
</p></div></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="Changes_to_Core_Requests"></a>Chapter 3. Changes to Core Requests</h1></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#Resource_ID_Usage">Resource ID Usage</a></span></dt><dt><span class="sect1"><a href="#Extension_Security">Extension Security</a></span></dt><dt><span class="sect1"><a href="#Keyboard_Security">Keyboard Security</a></span></dt><dt><span class="sect1"><a href="#Image_Security">Image Security</a></span></dt><dt><span class="sect1"><a href="#Property_Security">Property Security</a></span></dt><dt><span class="sect1"><a href="#Miscellaneous_Security">Miscellaneous Security</a></span></dt></dl></div><p>
A server supporting this extension modifies the handling of some core
requests in the following ways.
</p><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Resource_ID_Usage"></a>Resource ID Usage</h2></div></div></div><p>
If an untrusted client makes a request that specifies a resource ID that is
not owned by another untrusted client, a protocol error is sent to the
requesting client indicating that the specified resource does not exist.
The following exceptions apply. An untrusted client can:
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
use  the  QueryTree,  GetGeometry,  and  TranslateCoordinates  requests
without restriction.
    </p></li><li class="listitem"><p>
use colormap IDs that are returned in the default-colormap field of its
connection setup information in any colormap requests.
    </p></li><li class="listitem"><p>specify a root window as:</p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>
the drawable field of CreatePixmap, CreateGC, and QueryBestSize.
         </p></li><li class="listitem"><p>the parent field of CreateWindow.</p></li><li class="listitem"><p>
the window field of CreateColormap, ListProperties, and GetWindowAttributes.
         </p></li><li class="listitem"><p>the grab-window or confine-to fields of GrabPointer.
         </p></li><li class="listitem"><p>the grab-window field of UngrabButton.</p></li><li class="listitem"><p>
the destination of SendEvent, but only if all of the following are true.
(These conditions cover all the events that the ICCCM specifies with
a root window destination.)
         </p><div class="orderedlist"><ol class="orderedlist" type="i"><li class="listitem"><p>The propogate field of SendEvent is False.</p></li><li class="listitem"><p>
The   event-mask   field   of   SendEvent   is   ColormapChange,
StructureNotify, or the logical OR of SubstructureRedirect with
SubstructureNotify.
             </p></li><li class="listitem"><p>
The event type being sent is UnmapNotify, ConfigureRequest, or
ClientMessage.
             </p></li></ol></div></li><li class="listitem"><p>
the window field of ChangeWindowAttributes, but only if the value-mask
contains only event-mask and the corresponding value is StructureNotify,
PropertyChange, or the logical OR of both.
         </p></li></ol></div></li></ol></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
ISSUE: are root window exceptions needed for these? WarpPointer, ReparentWindow
(parent), CirculateWindow, QueryPointer (emacs does this), GetMotionEvents.
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Extension_Security"></a>Extension Security</h2></div></div></div><p>
This extension introduces the notion of secure and insecure extensions. A
secure extension is believed to be safe to use by untrusted clients; that
is, there are no significant security concerns known that an untrusted
client could use to destroy, modify, or steal data of trusted clients. This
belief may be founded on a careful analysis of the extension protocol,
its implementation, and measures taken to "harden" the extension to close
security weaknesses. All extensions not considered secure are called
insecure. The implementation details of how an extension is identified as
secure or insecure are beyond the scope of this specification.
</p><p>
<code class="function">ListExtensions</code> will only return names of secure
extensions to untrusted clients.
</p><p>
If an untrusted client uses <code class="function">QueryExtension</code> on an
insecure extension that the server supports, the reply will have the
present field set to False and the major-opcode field set to zero to
indicate that the extension is not supported.
</p><p>
If an untrusted client successfully guesses the major opcode of an
insecure extension, attempts by it to execute requests with that major
opcode will fail with a Request error.
</p></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Keyboard_Security"></a>Keyboard Security</h2></div></div></div><p>
The protocol interpretation changes in this section are intended to prevent
untrusted applications from stealing keyboard input that was meant for
trusted clients and to prevent them from interfering with the use of the
keyboard.
</p><p>
The behavior of some keyboard-related requests and events is modified when
the client is untrusted depending on certain server state at the time of
request execution or event generation. Specifically, if a hypothetical
keyboard event were generated given the current input focus, pointer
position, keyboard grab state, and window event selections, and if that
keyboard event would not be delivered to any untrusted client, the
following changes apply:
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
The bit vector representing the up/down state of the keys returned by
<code class="function">QueryKeymap</code> and
<code class="function">KeymapNotify</code> is all zeroes.
    </p></li><li class="listitem"><p>GrabKeyboard returns a status of AlreadyGrabbed.</p></li><li class="listitem"><p>
<code class="function">SetInputFocus</code> does nothing. Note that this means the
Globally Active
Input and WM_TAKE_FOCUS mechanisms specified in the ICCCM will
not work with untrusted clients.
    </p></li><li class="listitem"><p>
Passive grabs established by GrabKey that would otherwise have activated
do not activate.
    </p></li></ol></div><p>
If an untrusted client attempts to use any of the following requests, the
only effect is that the client receives an Access error: SetModifierMapping,
ChangeKeyboardMapping, ChangeKeyboardControl.
</p><p>
If an InputOnly window owned by an untrusted client has a parent owned by a
trusted client, all attempts to map the window will be ignored. This includes
mapping attempts resulting from MapWindow, MapSubwindows, ReparentWindow,
and save-set processing.
</p><p>
However, if the parent of an InputOnly window owned by an untrusted client
is the root window, attempts to map that window will be performed as
expected. This is in line with the root window exceptions above.
</p></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Image_Security"></a>Image Security</h2></div></div></div><p>
It should be impossible for an untrusted client to retrieve the image
contents of a trusted window unless a trusted client takes action to allow
this. We introduce the following defenses in support of this requirement.
</p><p>
The restrictions on resource ID usage listed above prevent untrusted clients
from using GetImage directly on windows not belonging to trusted clients.
</p><p>
If an untrusted client tries to set the background-pixmap attribute of an
untrusted window to None, the server will instead use a server-dependent
background which must be different than None.
</p><p>
The X protocol description of <code class="function">GetImage</code> states that the
returned contents of regions of a window obscured by noninferior windows are
undefined if the window has no backing store. Some implementations return the
contents of the obscuring windows in these regions. When an untrusted client
uses <code class="function">GetImage</code>, this behavior is forbidden; the server must
fill the obscured regions in the returned image with a server-dependent pattern.
</p><p>
If an untrusted window has trusted inferiors, their contents are vulnerable
to theft via <code class="function">GetImage</code> on the untrusted parent, as well
as being vulnerable to destruction via drawing with subwindow-mode
IncludeInferiors on the untrusted parent. An untrusted window having trusted
inferiors can only occur at the request of a trusted client. It is expected
to be an unusual configuration.
</p></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Property_Security"></a>Property Security</h2></div></div></div><p>
Unlike the other security provisions described in this document, security for
property access is not amenable to a fixed policy because properties are
used for inter-client communication in diverse ways and may contain data of
varying degrees of sensitivity. Therefore, we only list the possible
restrictions the server may decide to impose on use of properties on trusted
windows by untrusted clients. How the server chooses which restrictions from
this list to apply to a particular property access is implementation dependent
  <a href="#ftn.idp47935904" class="footnote" id="idp47935904"><sup class="footnote">[1]</sup></a>.
</p><p>The X Protocol property requests are
<code class="function">ChangeProperty</code>,
<code class="function">GetProperty</code>,
<code class="function">DeleteProperty</code>,
<code class="function">RotateProperties</code>, and
<code class="function">ListProperties</code>. For these requests, the server can
allow the request to execute normally (as if it had been issued by a
trusted client), ignore the request completely (as if it were a NoOperation),
or ignore the request except to send an Atom error to the client. Ignoring
a <code class="function">ListProperties</code> request means replying that
the window has no properties. <code class="function">ListProperties</code> may also
reply with a subset of the existing properties if the server is doing
property hiding; see below. An ignored <code class="function">GetProperty</code>
request may reply that the property does not exist, or that it exists but
contains no data.
</p><p>
The server may decide to hide certain properties on certain windows from
untrusted clients
  <a href="#ftn.idp47943600" class="footnote" id="idp47943600"><sup class="footnote">[2]</sup></a>.
If a property is to be hidden, it must be done consistently to avoid
confusing clients.  This means that for untrusted clients:
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
That property should not be returned by
<code class="function">ListProperties</code>.
    </p></li><li class="listitem"><p>
<code class="function">PropertyNotify</code> events should not be sent for that
property.</p></li><li class="listitem"><p>
<code class="function">GetProperty</code> on that property should reply that the
property does not exist (the return type is None, the format and
bytes-after are zero, and the value is empty).
    </p></li></ul></div><p>
For a property that the server is protecting but not hiding, consistency
must also be maintained:
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
That property should be returned by <code class="function">ListProperties</code>.
    </p></li><li class="listitem"><p>
<code class="function">PropertyNotify</code> events should be sent for that property.
    </p></li><li class="listitem"><p>
<code class="function">GetProperty</code> on that property should reply that the
property exists (if it really does) but the value is empty
(return type and format are their real values, and the "length of value"
field in the reply is zero).
    </p></li></ul></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Miscellaneous_Security"></a>Miscellaneous Security</h2></div></div></div><p>
If an untrusted client attempts to use
<code class="function">ChangeHosts</code>,
<code class="function">ListHosts</code>, or
<code class="function">SetAccessControl</code>,
the only effect is that the client receives an Access error.
</p><p>
If an untrusted client attempts to use <code class="function">ConvertSelection</code>
on a selection with a trusted selection owner window, the server generates
a SelectionNotify event to the requestor with property None.
</p></div><div class="footnotes"><br /><hr style="width:100; text-align:left;margin-left: 0" /><div id="ftn.idp47935904" class="footnote"><p><a href="#idp47935904" class="para"><sup class="para">[1] </sup></a>
In the X Consortium server implementation, property access is controlled by
a configuration file; see the -sp option in the Xserver(1) manual page.
  </p></div><div id="ftn.idp47943600" class="footnote"><p><a href="#idp47943600" class="para"><sup class="para">[2] </sup></a>
The X Consortium server implementation does not currently provide a way to
hide properties.
  </p></div></div></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="New_Authorization_Method"></a>Chapter 4. New Authorization Method</h1></div></div></div><p>
This extension includes a new authorization method named
"XC-QUERY-SECURITY-1".  Its purpose is to allow an external agent such as
the X firewall proxy to probe an X server to determine whether that server
meets certain security criteria without requiring the agent to have its
own authorization for that server. The agent may use the returned information
to make a decision. For example, the X firewall proxy may choose not to
forward client connections to servers that do not meet the criteria.
</p><p>
To use this authorization method, the client (or proxy) sends
"XC-QUERY-SECURITY-1" as the authorization-protocol-name in the initial
connection setup message. The authorization-protocol-data may be empty or
may contain additional security criteria desribed below. If the success
field of the server's reply is Authenticate, the server supports the
security extension, and the server meets all specified additional security
criteria. In this case, the client should resend the initial connection
setup message substituting the authorization protocol name and data
that should be used to authorize the connection. If the success field of the
server's reply is anything other than Authenticate, either the server does not
support the security extension, does not meet (or cannot determine if it
meets) all of the additional security criteria, or chooses for internal reasons
not to answer with Authenticate. In this case, the client should close the
connection.
</p><p>
If the authorization-protocol-data sent with "XC-QUERY-SECURITY-1" is not
empty, it specifies additional security criteria for the server to check, as
follows.
</p><p>
<code class="function">authorization-protocol-data</code>
</p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /></colgroup><tbody><tr><td align="left">
          <p>policy-mask</p>
        </td><td align="left">
          <p>BITMASK</p>
        </td></tr><tr><td align="left">
          <p>policies</p>
        </td><td align="left">
          <p>LISTofSECURITYPOLICY</p>
        </td></tr></tbody></table></div><p>
The policy-mask field is any logical-OR combination of the constants
Extensions and SitePolicies. For each bit set in policy-mask, there is a
SECURITYPOLICY element in policies. The nth element in policies corresponds
to the nth 1-bit in policy-mask, counting upward from bit 0.
</p><p><code class="function">SECURITYPOLICY</code></p><div class="informaltable"><table border="0"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /></colgroup><tbody><tr><td align="left">
          <p>policy-type</p>
        </td><td align="left">
          <p>{Disallow, Permit}</p>
        </td></tr><tr><td align="left">
          <p>names</p>
        </td><td align="left">
          <p>LISTofSTR</p>
        </td></tr></tbody></table></div><p>
For a SECURITYPOLICY corresponding to policy-mask Extensions, if
policy-type is Disallow the server is required to consider as insecure
all extensions given in names.  No policy is specified for extensions
not listed in names. If policy-type is Permit the server may consider
only those extensions given in names to be secure; all other extensions
must be treated as insecure. If these constraints are not met, the server
should not return Authenticate in the success field of the reply.
Servers can but need not dynamically configure themselves in response
to an Extensions SECURITYPOLICY; a conforming server might simply compare
the policy with a compiled-in table of extensions and their security status.
</p><p>
For a SECURITYPOLICY corresponding to policy-mask SitePolicies, policy-type
Disallow means the server must not have been configured with any of the site
policies given in names. Policy-type Permit means the server must have
been configured with at least one of the site policies given in names. If
these constraints are not met, the server should not return Authenticate in
the success field of the reply.
</p><p>
SitePolicies provide a way to express new forms of security-relevant
information that could not be anticipated at the time of this writing.
For example, suppose the server is found to have a critical security defect.
When a fix is developed, a site policy string could be associated with the
fix. Servers with the fix would advertise that site policy, and the X
firewall proxy would specify that site policy in a SECURITYPOLICY with
policy-type Permit.
</p></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="Encoding"></a>Chapter 5. Encoding</h1></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#Types">Types</a></span></dt><dt><span class="sect1"><a href="#Request_Encoding">Request Encoding</a></span></dt><dt><span class="sect1"><a href="#Event_Encoding">Event Encoding</a></span></dt><dt><span class="sect1"><a href="#Authorization_Method_Encoding">Authorization Method Encoding</a></span></dt></dl></div><p>
Please refer to the X11 Protocol Encoding document as this section
uses syntactic conventions and data types established there.
</p><p>
The name of this extension is "SECURITY".
</p><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Types"></a>Types</h2></div></div></div><p>
AUTHID: CARD32
</p></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Request_Encoding"></a>Request Encoding</h2></div></div></div><p>
SecurityQueryVersion
</p><div class="literallayout"><p><br />
1         CARD8         major-opcode<br />
1         0                minor-opcode<br />
2         2              request length<br />
2         CARD16        client-major-version<br />
2         CARD16        client-minor-version<br />
=&gt;<br />
1         1     Reply<br />
1               unused<br />
2         CARD16    sequence number<br />
4         0     reply length<br />
2         CARD16    server-major-version<br />
2         CARD16    server-minor-version<br />
20                            unused<br />
</p></div><p>
<code class="function">SecurityRevokeAuthorization</code>
</p><div class="literallayout"><p><br />
1         CARD8          major-opcode<br />
1         2                  minor-opcode<br />
2         2                  request length<br />
4         AUTHID         authorization-id<br />
</p></div><p>
SecurityGenerateAuthorization
</p><div class="literallayout"><p><br />
1         CARD8              major-opcode<br />
1         1                      minor-opcode<br />
2         3 + (m+n+3)/4 + s  request length<br />
2         CARD16             m, number of bytes in authorization protocol name<br />
2         CARD16             n, number of bytes in authorization data<br />
m        STRING8             authorization protocol name<br />
n         STRING8            authorization protocol data<br />
p                                  unused, p=pad(m+n)<br />
4         BITMASK          value-mask (has s bits set to 1)<br />
       #x00000001          timeout<br />
       #x00000002          trust-level<br />
       #x00000004          group<br />
       #x00000008          event-mask<br />
4s        LISTofVALUE       value-list<br />
</p></div><p>
VALUES
</p><div class="literallayout"><p><br />
4      CARD32        timeout<br />
4                          trust-level<br />
       0                   SecurityClientTrusted<br />
       1                   SecurityClientUntrusted<br />
4      XID              group<br />
0                          None<br />
4      CARD32           event-mask<br />
       #x00000001       SecurityAuthorizationRevoked<br />
=&gt;<br />
1         1               Reply<br />
1                         unused<br />
2         CARD16     sequence number<br />
4         (q+3)/4        reply length<br />
4         AUTHID       authorization-id<br />
2         CARD16       data-length<br />
18                        unused<br />
q         STRING8      authorization-data-return<br />
r                         unused, r=pad(q)<br />
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Event_Encoding"></a>Event Encoding</h2></div></div></div><p>
<code class="function">SecurityAuthorizationRevoked</code>
</p><div class="literallayout"><p><br />
1         0+extension event base        code<br />
1                                                 unused<br />
2         CARD16                             sequence number<br />
4         AUTHID                             authorization id<br />
24                                                unused<br />
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Authorization_Method_Encoding"></a>Authorization Method Encoding</h2></div></div></div><p>
For authorization-protocol-name "XC-QUERY-SECURITY-1", the
authorization-protocol-data is interpreted as follows:
</p><p>
<code class="function">authorization-protocol-data</code>
</p><div class="literallayout"><p><br />
1         BITMASK                              policy-mask<br />
          #x00000001            Extensions<br />
          #x00000002            SitePolicies<br />
m        LISTofSECURITYPOLICY                  policies<br />
</p></div><p>
<code class="function">SECURITYPOLICY</code>
</p><div class="literallayout"><p><br />
1                                                             policy-type<br />
          0                         Permit<br />
          1                         Disallow<br />
1         CARD8                                          number of STRs in names<br />
n         LISTofSTR                                      names<br />
</p></div><p>
LISTofSTR has the same encoding as in the X protocol: each STR is a single
byte length, followed by that many characters, and there is no padding or
termination between STRs.
</p></div></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="C_Language_Binding"></a>Chapter 6. C Language Binding</h1></div></div></div><p>
The header for this extension is &lt;X11/extensions/security.h&gt;. All
identifier names provided by this header begin with XSecurity.
</p><p>
All functions that have return type Status will return nonzero for
success and zero for failure.
</p><div class="funcsynopsis"><a id="XSecurityQueryExtension"></a><p><code class="funcdef">Status <strong class="fsfunc">XSecurityQueryExtension</strong>(</code>Display <var class="pdparam"> *dpy</var>, int <var class="pdparam"> *major_version_return</var>, int <var class="pdparam"> *minor_version_return</var><code>)</code>;</p></div><p>
<a class="xref" href="#XSecurityQueryExtension"><code class="function">XSecurityQueryExtension</code></a> sets major_version_return and
minor_version_return to the major and minor Security protocol version
supported by the server. If the Security library is compatible with the
version returned by the server, it returns nonzero. If dpy does not support
the Security extension, or if there was an error during communication with
the server, or if the server and library protocol versions are incompatible,
it returns zero. No other XSecurity functions may be called before this
function. If a client violates this rule, the effects of all subsequent
XSecurity calls that it makes are undefined.
</p><div class="funcsynopsis"><a id="XSecurityAllocXauth"></a><p><code class="funcdef">Xauth *<strong class="fsfunc">XSecurityAllocXauth</strong>(</code><var class="pdparam">void</var><code>)</code>;</p></div><p>
In order to provide for future evolution, Xauth structures are used to
pass and return authorization data, and the library provides ways to
allocate and deallocate them.
</p><p>
<a class="xref" href="#XSecurityAllocXauth"><code class="function">XSecurityAllocXauth</code></a> must be used to allocate the
Xauth structure that is passed to
<a class="xref" href="#XSecurityGenerateAuthorization"><code class="function">XSecurityGenerateAuthorization</code></a>.
</p><p>
For the purposes of the Security extension, the Xauth structure has
the following fields:
</p><div class="informaltable"><table border="1"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /><col align="left" class="c3" /></colgroup><thead><tr><th align="left">Type</th><th align="left">Field name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left">
          <p>unsigned short</p>
        </td><td align="left">
          <p>name_length</p>
        </td><td align="left">
          <p>number of bytes in name</p>
        </td></tr><tr><td align="left">
          <p>char *</p>
        </td><td align="left">
          <p>name</p>
        </td><td align="left">
          <p>authorization protocol name</p>
        </td></tr><tr><td align="left">
          <p>unsigned short</p>
        </td><td align="left">
          <p>data_length</p>
        </td><td align="left">
          <p>number of bytes in data</p>
        </td></tr><tr><td align="left">
          <p>char *</p>
        </td><td align="left">
           <p>data</p>
        </td><td align="left">
          <p>authorization protocol data</p>
        </td></tr></tbody></table></div><p>
The Xauth structure returned by this function is initialized as follows:
name_length and data_length are zero, and name and data are NULL.
</p><div class="funcsynopsis"><a id="XSecurityFreeXauth"></a><p><code class="funcdef">void <strong class="fsfunc">XSecurityFreeXauth</strong>(</code>Xauth<var class="pdparam"> *auth</var><code>)</code>;</p></div><p>
<a class="xref" href="#XSecurityFreeXauth"><code class="function">XSecurityFreeXauth</code></a> must be used to free Xauth
structures allocated by
<a class="xref" href="#XSecurityAllocXauth"><code class="function">XSecurityAllocXauth</code></a> or returned by
<a class="xref" href="#XSecurityGenerateAuthorization"><code class="function">XSecurityGenerateAuthorization</code></a>. It is the
caller's responsibility to fill in the name and data fields of Xauth structures
allocated with <a class="xref" href="#XSecurityAllocXauth"><code class="function">XSecurityAllocXauth</code></a>, so this function
will not attempt to free them. In contrast, all storage associated with
Xauth structures returned from
<a class="xref" href="#XSecurityGenerateAuthorization"><code class="function">XSecurityGenerateAuthorization</code></a> will be freed by this
function, including the name and data fields.
</p><div class="funcsynopsis"><a id="XSecurityRevokeAuthorization"></a><p><code class="funcdef">Bool <strong class="fsfunc">XSecurityRevokeAuthorization</strong>(</code>Display<var class="pdparam"> *dpy</var>, XSecurityAuthorization<var class="pdparam"> auth_id</var><code>)</code>;</p></div><p>
<a class="xref" href="#XSecurityRevokeAuthorization"><code class="function">XSecurityRevokeAuthorization</code></a> deletes the authorization
specified by auth_id, which must be a value returned in the auth_id_return
parameter of <a class="xref" href="#XSecurityGenerateAuthorization"><code class="function">XSecurityGenerateAuthorization</code></a>. All
clients that connected with that authorization are be killed. Subsequently,
clients that attempt to connect using that authorization will be refused.
</p><div class="funcsynopsis"><a id="XSecurityGenerateAuthorization"></a><p><code class="funcdef">Xauth *<strong class="fsfunc">XSecurityGenerateAuthorization</strong>(</code>Display<var class="pdparam"> *dpy</var>, Xauth<var class="pdparam"> *auth_in</var>, unsigned long<var class="pdparam"> valuemask</var>, XSecurityAutorizationAttributes <var class="pdparam"> *attributes</var>, XSecurityAutorization<var class="pdparam"> *auth_id_return</var><code>)</code>;</p></div><p>
<a class="xref" href="#XSecurityGenerateAuthorization"><code class="function">XSecurityGenerateAuthorization</code></a> creates a new
authorization with the specified attributes. The auth_in argument must be
allocated by <a class="xref" href="#XSecurityAllocXauth"><code class="function">XSecurityAllocXauth</code></a>. The
name and name_length fields of auth_in should be initialized to the
authorization protocol name and its length in characters respectively.
If there is authorization data, the data and data_length fields of
auth_in should be initialized to the data and its length in characters
respectivley. The library does not assume that name and data are
null-terminated strings. The auth_in argument must be freed with
<a class="xref" href="#XSecurityFreeXauth"><code class="function">XSecurityFreeXauth</code></a>.
</p><p>
The XSecurityAuthorizationAttributes structure has the following fields:
</p><div class="informaltable"><table border="1"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /><col align="left" class="c3" /></colgroup><thead><tr><th align="left">Type</th><th align="left">Field name</th><th align="left">Mask</th></tr></thead><tbody><tr><td align="left">
          <p>unsigned int</p>
        </td><td align="left">
          <p>trust_level</p>
        </td><td align="left">
          <p>XSecurityTrustLevel</p>
        </td></tr><tr><td align="left">
          <p>unsigned int</p>
        </td><td align="left">
          <p>timeout</p>
        </td><td align="left">
          <p>XSecurityTimeout</p>
        </td></tr><tr><td align="left">
          <p>XID</p>
        </td><td align="left">
          <p>group</p>
        </td><td align="left">
          <p>XSecurityGroup</p>
        </td></tr><tr><td align="left">
          <p>long</p>
        </td><td align="left">
          <p>event_mask</p>
        </td><td align="left">
          <p>XSecurityEventMask</p>
        </td></tr></tbody></table></div><p>
These correspond to the trust-level, timeout, group, and event-mask
described in the SecurityGenerateAuthorization protocol request. The
caller can fill in values for any subset of these attributes. The valuemask
argument must be the bitwise OR of the symbols listed in the Mask column
for all supplied attributes. The event_mask attribute can be None,
XSecurityAuthorizationRevokedMask, or XSecurityAllEventMasks. In this
revision of the protocol specification XSecurityAllEventMasks is equivalent
to XSecurityAuthorizationRevokedMask. If the caller does not need to
specify any attributes, the attributes argument can be NULL, and the
valuemask argument must be zero.
</p><p>
If the function fails, NULL is returned and auth_id_return is filled in
with zero.  Otherwise, a pointer to an Xauth structure is returned. The name
and name_length fields of the returned Xauth structure will be copies of the
name that was passed in, and the data and data_length fields will be set to
the authorization data returned by the server. The caller should not assume
that name and data are null-terminated strings. If no authorization data was
returned by the server, the data and data_length fields will be set to NULL
and zero repectively. The returned Xauth structure must be freed with
<a class="xref" href="#XSecurityFreeXauth"><code class="function">XSecurityFreeXauth</code></a>; the caller should not use any other
means free the structure or any of its components. The auth_id_return
argument will be filled in with the non-zero authorization id of the created
authorization.
</p><p>
The XSecurityAuthorizationRevokedEvent structure has the following fields:
</p><div class="informaltable"><table border="1"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /><col align="left" class="c3" /></colgroup><thead><tr><th align="left">Type</th><th align="left">Field name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left">
          <p>int</p>
        </td><td align="left">
          <p>type</p>
        </td><td align="left">
          <p>event base + XSecurityAuthorizationRevoked</p>
        </td></tr><tr><td align="left">
          <p>unsigned long</p>
        </td><td align="left">
          <p>serial</p>
        </td><td align="left">
          <p># of last request processed by server</p>
        </td></tr><tr><td align="left">
          <p>Bool</p>
        </td><td align="left">
          <p>send_event</p>
        </td><td align="left">
          <p>true if this came from SendEvent</p>
        </td></tr><tr><td align="left">
          <p>Display*</p>
        </td><td align="left">
          <p>display</p>
        </td><td align="left">
          <p>Display the event was read from</p>
        </td></tr><tr><td align="left">
          <p>XSecurityAuthorization</p>
        </td><td align="left">
          <p>auth_id</p>
        </td><td align="left">
          <p>revoked authorization id</p>
        </td></tr></tbody></table></div></div></div></body></html>