blob: c87c02ba371020b799a105d03ad041df024a3f38 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
|
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
xmlns:a="http://freeipa.org/xml/rng/ns/annotations/1.0">
<a:doc> Sudo options configuration (Defaults) </a:doc>
<include href="options.rng"/>
<start ns="http://freeipa.org/xml/rng/sudo/sudoOptions/1.0">
<element name="sudoOptions">
<ref name="options"/>
<!-- we can enclose anything -->
<!--
NOTE: This allows only a single element to be enclosed.
The problem with allowing multiple elements is, how to
resolve conflicting configs?
<sudoOptions ...>
<posixGroup name="wheel">
<sudoers .../>
</posixGroup>
<posixGroup name="staff">
<sudoers .../>
</posixGroup>
<posixUser name="user">
<sudoers .../>
</posixGroup>
</sudoOptions>
If user foo is in both groups, and (e.g.) conflicting
options are used in the <sudoers> element, which applies?
For the <posixUser> case, we could simply say it is more
specific and it wins, but not so easy for the groups case.
NOTE: This is a general problem. Even if sudoOptions allows only
a single element, what about other grouping elements?
-->
<ref name="anyElement"/>
</element>
</start>
<!--
This allows anything in another namespace.
The way nsName works requires that this be in each schema (grammar);
it cannot be included.
-->
<define name="anyElement">
<zeroOrMore>
<element>
<anyName>
<except>
<nsName/>
<nsName ns=""/>
<!--
<nsName ns="http://freeipa.org/xml/rng/sudo/sudoOptions/1.0"/>
-->
</except>
</anyName>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="anyElement"/>
</choice>
</zeroOrMore>
</element>
</zeroOrMore>
</define>
</grammar>
|
