Private branches don't sync for Admin and Setup by default?
(1) By Warren Young (wyoung) on 2019-08-29 01:39:50 [link] [source]
While working on the new user capabilities doc, I came across this old doco:
you have to enable the "Private" capability (the "x" capability) in order to enable private branch syncing. The Admin ("a") and Superuser ("s") do not imply Private ("x"); you'll have to set "x" in addition to "a" or "s".
That seems to be contradicted by the code. My understanding of src/xfer.c is weak, but I see a bunch of tests on g.perm.Private, which is set by that code. Is the doc wrong, or does the code get overridden in some way I don't see?
I'd fix the doc to match the code, but it looks like it's the code that's wrong, not the doc.
If someone changes the code to fix the doc, then that affects my new capability reference, which currently claims that Setup and Admin both get all caps, except for "s" for Admin. This would be an exception to that.
(2) By Warren Young (wyoung) on 2019-09-03 21:34:53 in reply to 1 [link] [source]
"Private" capability (the "x" capability) in order to enable private branch syncing.
Bump. Once we decide which is wrong, the code or the docs, and fix that, then the caps-doc branch can merge down to trunk, as far as I'm concerned.
Personally, I'd prefer that the code remain the same, and we fix the doc. I can do the work, I just need to know if such a commit is actually correct first.
(3) By Richard Hipp (drh) on 2019-09-03 23:39:19 in reply to 2 [link] [source]
I suppose it would be best to modify the docs to match the implementation. The implementation has been that way for years, and nobody has complained.
(4) By ckennedy on 2019-09-03 23:56:44 in reply to 2 [link] [source]
It also appears that Setup and Admin are missing WrUnver (cap 'y') from my reading of the linked code (last time I did C code was 20 years ago). Obviously this isn't stopping the write, so it might be checked elsewhere as well. The organization of the code makes it a little hard to audit visually as well, since the caps are out of order between what is assigned to Admin and those that follow.
(5) By Richard Hipp (drh) on 2019-09-04 00:18:56 in reply to 4 [source]
That is by design.
Cap 'y' has such a high potential for abuse (it can be used to uploaded download products) that it is off by default for everyone, and needs to be turned on on a case-by-case basis.
Of course, a Setup user can enable 'y' and do anything then turn it back off, and then purge the troublesome change records from the log. But at least that user would have to work at it.
It is best to keep capability 'y' off by default for everyone.
(6) By Andy Bradford (andybradford) on 2019-09-04 06:20:29 in reply to 1 [link] [source]
It seems that the code was updated a while ago (2016) here with rationale given in the commit comment: https://www.fossil-scm.org/home/info/b2411302 Apparently the documentation did not get updated at that time. Andy
(7) By Richard Hipp (drh) on 2019-09-04 11:56:30 in reply to 6 [link] [source]
That reminds me of why "x" was original separate from "a" and "s". Separating "x" out allows accounts to be created with high privilege that do risk accidentally syncing private content. It was an extra layer of defense against configuration errors.
Now that my memory is refreshed, I recommend backing out the change that Andy links above.
(8) By Warren Young (wyoung) on 2019-09-04 23:41:04 in reply to 7 [link] [source]
I've written a new section in the new caps docs, "Dangerous Capabilities Initially Denied to Everyone."
I've decided to keep the "all-powerful Setup user" language because a Setup user can grant themselves both capabilities. They just have to make the decision to grant themselves these powers.