Fossil Forum

Security Audit shows write ticket access, but developer perms are: 4bdei
Login

Security Audit shows write ticket access, but developer perms are: 4bdei

Security Audit shows write ticket access, but developer perms are: 4bdei

(1) By anonymous on 2020-03-12 01:19:49 [link] [source]

Hi all:

I am running fossil version: afb4f74808

The Security Audit page shows the developer "user" has write access to tickets. However the permissions for the develop user are: 4bdei. This should turn off access to tickets for the developer right?

Can anybody explain this?

Thanks,

-- rouilj

(2) By Richard Hipp (drh) on 2020-03-12 01:51:25 in reply to 1 [link] [source]

Possibly now fixed on trunk due to a check-in I just made.

(3) By anonymous on 2020-03-12 02:40:41 in reply to 2 [link] [source]

I updated and reinstalled. Using [ba56f5e5cc] I still see the problem.

Other ideas?

-- rouilj

(4) By Richard Hipp (drh) on 2020-03-12 10:56:29 in reply to 3 [source]

Please try again with the new trunk check-in.

Notes

The 'd' capability, which is labeled "Delete wiki and tickets", is not used for anything inside of Fossil. In other words, it does not provide any capabilities. With the block-chain data model, it is not possible to "delete" wiki or tickets.

The 'd' capability is apparently a hold-over from CVSTrac. CVSTrac had a centralized server and so it was actually possible to delete things in that system. Much of the initial Fossil code was copied from CVSTrac. Apparently, I never removed the 'd' capability, even though it no longer makes any sense.

(5) By anonymous on 2020-03-12 13:16:07 in reply to 4 [link] [source]

The summary now looks like:

  Code Forum Tickets Wiki Unversioned Content
"nobody" read read off read read
"anonymous" read write off write read
"reader" read write off write read
"developer" write write off write read
New User Default read write off write read
Adminstrator write write write write read

with [3941824d85].

One thing I don't get is why the admin has read access to unversioned. Shouldn't that be write?

Also congrats on getting back a free letter for the permissions strings.

I assume that deleting a ticket or wiki is done by shunning the artifact. Is this correct?

-- rouilj

(9) By Warren Young (wyoung) on 2020-03-12 17:09:31 in reply to 5 [link] [source]

One thing I don't get is why the admin has read access to unversioned. Shouldn't that be write?

No, it should not, on purpose.

Also congrats on getting back a free letter for the permissions strings.

I'm not sure cap letter "d" can be considered liberated for quite some time to come. It's stored as a string in each new repo, so whatever reuses this letter in the future will automatically be granted to the Developer user category by default. Therefore, either:

  1. Users will have to be warned to remove "d" from the default "dei" user cap set before upgrading to any version that uses "d" for something else. (And many Fossil users will ignore whatever advance warning we do give!)

  2. Any future actually-useful capability assigned "d" will have to be appropriate for Developer class users to have, broadly speaking.

(6) By anonymous on 2020-03-12 16:27:04 in reply to 4 [link] [source]

Apparently, I never removed the 'd' capability, even though it no longer makes any sense.

A possible re-interpretation of 'd' would be to hide/unhide tickets and wiki pages.

Also, I didn't think tickets or wiki pages were part of "the blockchain". I thought each ticket/wiki page was its own blockchain, independent of the DAG revision tree that tracks file (including embedded docs) revisions.

If that's the case, then a ticket or wiki page could be deleted by removing by removing the blockchain for that ticket or wiki page.

(Though, I think hide/unhide is a better idea. If a ticket/wiki page truly needs to be removed, its artifacts can be shunned.)

(7) By Stephan Beal (stephan) on 2020-03-12 16:46:51 in reply to 6 [link] [source]

Also, I didn't think tickets or wiki pages were part of "the blockchain". I thought each ticket/wiki page was its own blockchain, independent of the DAG revision tree that tracks file (including embedded docs) revisions.

That's effectively true, but tickets and wikis may contain links to arbitrary other elements in the repo, and in turn can be linked to by other elements, so they're kind of "indirectly" part of the blockchain.

However, if a wiki's whole existence were wiped out via deletion of its own private strip of the chain, any links to that page would be invalidated or (worse) perhaps point to different content than intended if the wiki page's name were later reused for a different purpose. (That's analogous to re-using a free()d-then-re-allocated pointer in C, in that the pointer itself is valid, but very probably doesn't point to what it initially pointed to.) It would become impossible to distinguish between a link which points to a now-deleted page amd a link to a page which never existed. Whether that distinction is significant or not is of course debatable, but the current method of simply emptying out a wiki page to signal it as "deleted" doesn't have that property.

(8) By Warren Young (wyoung) on 2020-03-12 17:04:49 in reply to 4 [link] [source]

I never removed the 'd' capability, even though it no longer makes any sense.

I made a more extensive removal here.

Is there any good reason not to merge it to trunk?

(10) By Richard Hipp (drh) on 2020-03-12 17:19:14 in reply to 8 [link] [source]

If you could, please first add a comment some place (or places) obvious to warn future maintainers that reusing the 'd' capability is dangerous. There might be many repos in circulation that have users with the 'd' capability already.

The comment should be in some spot that a future maintainer would have to edit in order to be able to reuse the 'd' capability. In other words, the comment should be in a place where it will be difficult to overlook.

(11) By Warren Young (wyoung) on 2020-03-12 18:19:46 in reply to 10 [link] [source]

please first add a comment some place (or places)

Done.

There might be many repos in circulation that have users with the 'd' capability already.

It should be all of them, to a first approximation, since it was assigned to Developer by default. I'd guess that the percentage of extant repos that have either removed "d" from Developer category or who have moved it elsewhere is in the single digits.

The latest checkin on that branch therefore repurposes the check for "d" cap in the Security Audit to warn that it should be removed from current repos.