doc: update documentation with own_prefix policy rules

https://bugs.freedesktop.org/show_bug.cgi?id=46886
This commit is contained in:
Alban Crequy 2012-03-04 15:18:38 +00:00
parent 3c7c255ee7
commit 97c11fe286
2 changed files with 18 additions and 0 deletions

View file

@ -512,6 +512,7 @@ statements, and works just like &lt;deny&gt; but with the inverse meaning.</para
eavesdrop="true" | "false"
own="name"
own_prefix="name"
user="username"
group="groupname"
</literallayout> <!-- .fi -->
@ -590,6 +591,13 @@ the character "*" can be substituted, meaning "any." Complex globs
like "foo.bar.*" aren't allowed for now because they'd be work to
implement and maybe encourage sloppy security anyway.</para>
<para>&lt;allow own_prefix="a.b"/&gt; allows you to own the name "a.b" or any
name whose first dot-separated elements are "a.b": in particular,
you can own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c".
This is useful when services like Telepathy and ReserveDevice
define a meaning for subtrees of well-known names, such as
org.freedesktop.Telepathy.ConnectionManager.(anything)
and org.freedesktop.ReserveDevice1.(anything).</para>
<para>It does not make sense to deny a user or group inside a &lt;policy&gt;
for a user or group; user/group denials can only be inside

View file

@ -501,6 +501,7 @@ The possible attributes of these elements are:
eavesdrop="true" | "false"
own="name"
own_prefix="name"
user="username"
group="groupname"
.fi
@ -572,6 +573,15 @@ the character "*" can be substituted, meaning "any." Complex globs
like "foo.bar.*" aren't allowed for now because they'd be work to
implement and maybe encourage sloppy security anyway.
.PP
<allow own_prefix="a.b"/> allows you to own the name "a.b" or any
name whose first dot-separated elements are "a.b": in particular,
you can own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c".
This is useful when services like Telepathy and ReserveDevice
define a meaning for subtrees of well-known names, such as
org.freedesktop.Telepathy.ConnectionManager.(anything)
and org.freedesktop.ReserveDevice1.(anything).
.PP
It does not make sense to deny a user or group inside a <policy>
for a user or group; user/group denials can only be inside