|
1
|
# Implementation Details of User Capabilities |
|
2
|
|
|
3
|
## <a id="choices"></a>Capability Letter Choices |
|
4
|
|
|
5
|
We [assigned][ref] user capability characters using only lowercase ASCII |
|
6
|
letters at first, so those are the most important within Fossil: they |
|
7
|
control the functions most core to Fossil’s operation. Once we used up |
|
8
|
most of the lowercase letters, we started using uppercase, and then |
|
9
|
during the development of the [forum feature][for] we assigned most of |
|
10
|
the decimal numerals. All of the lowercase ASCII letters are now |
|
11
|
assigned. Eventually, we might have to start using ASCII |
|
12
|
punctuation and symbols. We expect to run out of reasons to define new caps before |
|
13
|
we’re forced to switch to Unicode, though the possibilities for [mnemonic][mn] |
|
14
|
assignments with emoji are intriguing. <span style="vertical-align: |
|
15
|
bottom">😉</span> |
|
16
|
|
|
17
|
The existing caps are usually mnemonic, especially among the |
|
18
|
earliest and therefore most central assignments, made when we still had |
|
19
|
lots of letters to choose from. There is still hope for good future |
|
20
|
mnemonic assignments among the uppercase letters, which are mostly still |
|
21
|
unused. |
|
22
|
|
|
23
|
|
|
24
|
## <a id="bitfield"></a>Why Not Bitfields? |
|
25
|
|
|
26
|
Some may question the use of ASCII character strings for [capability |
|
27
|
sets][ucap] instead of bitfields, which are more efficient, both in |
|
28
|
terms of storage and processing time. |
|
29
|
|
|
30
|
Fossil handles these character strings in one of two ways. For most HTTP |
|
31
|
hits, Fossil [expands][sexp] the string into a [`struct` full of |
|
32
|
flags][sff] so that later code can just do simple Boolean tests. In a |
|
33
|
minority of cases, where Fossil only needs to check for the presence of |
|
34
|
a single flag, it just does a [`strchr()` call][sc] on the string |
|
35
|
instead. |
|
36
|
|
|
37
|
Both methods are slower than bit testing in a bitfield, but keep the |
|
38
|
execution context in mind: at the front end of an HTTP request handler, |
|
39
|
where the nanosecond differences in such implementation details are |
|
40
|
completely swamped by the millisecond scale ping time of that repo’s |
|
41
|
network connection, followed by the required I/O to satisfy the request. |
|
42
|
Either method is plenty fast in that context. |
|
43
|
|
|
44
|
In exchange for this immeasurable cost per hit, we get human-readable |
|
45
|
capability sets. |
|
46
|
|
|
47
|
|
|
48
|
## <a id="filter"></a>Why Doesn’t Fossil Filter “Bad” Artifacts on Sync? |
|
49
|
|
|
50
|
Fossil is more trusting about the content it receives from a remote |
|
51
|
clone during sync than you might expect. Common manifestations of this |
|
52
|
design choice are: |
|
53
|
|
|
54
|
1. A user may be able to impersonate other users. This can be |
|
55
|
[accidental](./index.md#defuser) as well as purposeful. |
|
56
|
|
|
57
|
2. If your local system clock is out-of-sync with absolute time, |
|
58
|
artifacts committed to that repo will appear with the “wrong” time |
|
59
|
when sync’d. If the time sync error is big enough, it can make |
|
60
|
check-ins appear to go back in time and other bad effects. |
|
61
|
|
|
62
|
3. You can purposely overwrite good timestamps with bad ones and push |
|
63
|
those changes up to the remote with no interference, even though |
|
64
|
Fossil tries to make that a Setup-only operation. |
|
65
|
|
|
66
|
All of this falls out of two of Fossil’s design choices: sync is |
|
67
|
all-or-nothing, and [the Fossil hash tree][bc] is immutable. Fossil |
|
68
|
would have to violate one or both of these principles to filter such |
|
69
|
problems out of incoming syncs. |
|
70
|
|
|
71
|
We have considered auto-[shunning][shun] “bad” content on sync, but this |
|
72
|
is [difficult][asd] due to [the design of the sync protocol][dsp]. This |
|
73
|
is not an impossible set of circumstances, but implementing a robust |
|
74
|
filter on this input path would be roughly as difficult as writing a |
|
75
|
basic [inter-frame video codec][ifvc]: do-able, but still a lot of |
|
76
|
work. Patches to do this will be thoughtfully considered. |
|
77
|
|
|
78
|
We can’t simply change content as it arrives. Such manipulations would |
|
79
|
change the artifact manifests, which would change the hashes, which |
|
80
|
would require rewriting all parts of the block chain from that point out |
|
81
|
to the tips of those branches. The local Fossil repo must then go |
|
82
|
through the same process as the remote one on subsequent syncs in order |
|
83
|
to build up a sync sequence that the remote can understand. Even if |
|
84
|
you’re willing to accept all of that, this would break all references to |
|
85
|
the old artifact IDs in forum posts, wiki articles, check-in comments, |
|
86
|
tickets, etc. |
|
87
|
|
|
88
|
The bottom line here is that [**Clone**](./ref.html#g) and |
|
89
|
[**Write**](./ref.html#i) are a potent combination of user capabilities. |
|
90
|
Be careful who you give that pair to! |
|
91
|
|
|
92
|
|
|
93
|
----- |
|
94
|
|
|
95
|
*[Back to Administering User Capabilities](./)* |
|
96
|
|
|
97
|
<!-- add padding so anchor links always scroll ref’d section to top --> |
|
98
|
<div style="height: 75em"></div> |
|
99
|
|
|
100
|
[asd]: https://fossil-scm.org/forum/forumpost/ce4a3b5f3e |
|
101
|
[bc]: ../blockchain.md |
|
102
|
[dsp]: https://fossil-scm.org/fossil/doc/trunk/www/sync.wiki |
|
103
|
[for]: ./forum.wiki |
|
104
|
[ifvc]: https://en.wikipedia.org/wiki/Inter_frame |
|
105
|
[mn]: https://en.wikipedia.org/wiki/Mnemonic |
|
106
|
[ref]: ./ref.html |
|
107
|
[sexp]: /artifact?ln=1223-1298&name=889d6724 |
|
108
|
[sff]: /artifact?ln=80-117&name=52d2860f |
|
109
|
[sc]: https://en.cppreference.com/w/c/string/byte/strchr |
|
110
|
[shun]: ../shunning.wiki |
|
111
|
[ucap]: ./index.md#ucap |
|
112
|
|