As I continue to build test cases for the JSON support, I poked at this
sore spot that Stephan Beal hinted at in the JSON API documentation, and
indeed it does something possibly unexpected.
A timeline of checkin events can be retrieved in JSON over HTTP by GET
/json/timeline/checkin as long as your session is logged in and supplies
a suitable login cookie in the HTTP headers. The result is some JSON
that lists the most recent 20 events along with some details about each one.
However, if the targeted repository is not writable to the process that
is running fossil http to handle the request, SQLITE quite properly has
a problem with that and the request fails with status 500.
Or does it?
The test case makes the repo read only with chmod 444. The request looks
like:
GET /json/timeline/checkin HTTP/1.1
Host: localhost
User-Agent: Fossil-http-json
Cookie:
fossil-6abe36d55f19ba6b=91F19DBBAFAC0B24AC354B85AC0093F64017B48D85308C0A2D%2F6abe36d55f19ba6b%2FU1
And the actual result returned on stdout is:
RESULT: HTTP/1.0 200 OK
Date: Fri, 29 Jan 2016 23:45:52 GMT
Connection: close
X-UA-Compatible: IE=edge
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: application/json; charset=utf-8; charset=utf-8
Content-Length: 830
{"fossil":"c4f8d88fd91a8925f832e1b58228cdf7f8aff3c1","timestamp":1454111152,"command":"timeline/checkin","procTimeUs":15600,"procTimeMs":15,"payload":{"limit":20,"timeline":[{"type":"checkin","uuid":"eef120c2544ee61081eb5235a62b684d341b54b3","isLeaf":true,"timestamp":1454111146,"user":"","comment":"Create
new branch named \"alpha\" from
\"trunk\".","parents":["eb1170dd02a530786313200f462f4339406a684e"],"tags":["alpha","cancel"]},{"type":"checkin","uuid":"eb1170dd02a530786313200f462f4339406a684e","isLeaf":true,"timestamp":1454111145,"user":"Ross","comment":"empty
file","parents":["8774b9f6b80d1d51e6c181e096fe7936776ef0ea"],"tags":["trunk","blue"]},{"type":"checkin","uuid":"8774b9f6b80d1d51e6c181e096fe7936776ef0ea","isLeaf":false,"timestamp":1454111143,"user":"Ross","comment":"initial
empty check-in","tags":["trunk"]}]}}SQLITE_NOTICE: delayed 1375ms for
lock/sharing conflict at line 39704
SQLITE_CANTOPEN: os_win.c:39711: (5)
winOpen(c:\Users\Ross\Documents\tmp\ftest\json\.rep.fossil) - Access is
denied.
Sharp eyes will notice that two SQLITE messages tagged on after the JSON
output in the body. I can't entirely explain the SQLITE_NOTICE about
sharing conflicts, that appears to be a Windows symptom that is a
subject for another email after I understand how to provoke it. The
interesting bit is the SQLITE_CANTOPEN message claiming it was denied
access to the repository (which is actually named .rep.fossil, this is a
transient repository that exists only when tester.tcl is running my
json.test file).
Note that the HTTP claims "200 OK" right at the top. So where does a 500
status come from? The fossil http command exited non-zero because of
SQLITE_CANTOPEN, and the web server then naturally flushes any output
from its CGI process.
I'm not certain what the right action (if any) is here. It is probably a
technical violation of the HTTP standard to have more text after the
Content-Length is used up.
But is it a problem?
Is there an attack vector here?
Do other JSON requests also exhibit this behavior?
Thoughts?
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
