report in python, a first version
Sébastien de Menten
sdementen at gmail.com
Tue Nov 15 15:58:32 EST 2016
On Tue, Nov 15, 2016 at 6:41 PM, John Ralls <jralls at ceridwen.us> wrote:
> > On Nov 15, 2016, at 9:24 AM, Sébastien de Menten <sdementen at gmail.com>
> > On Tue, Nov 15, 2016 at 4:17 PM, John Ralls <jralls at ceridwen.us> wrote:
> > Sébastien,
> > That's a bit more "external" than I had in mind. The plug/connect any
> process part is a serious security issue.
> > I don't understand the point of the json file. Users will want the
> report to display and then to be able to open the report options dialog to
> make changes like selecting a date range or modifying the accounts reported
> on, and expect the report to regenerate when they click "Apply". ISTM to
> accomplish that the report module needs to be in control and to pass to the
> Python report-builder the options parameters. The second thing that won't
> work is using PyCash: The user wants a report on what her book looks like
> in memory, not what it looked like the last time she saved, so the report
> will need to use the python bindings and connect to the current session.
> > It looks to me from the Makefile.am that building guile-json requires
> Guile-2.0, which you won't have if you're using the Guile in the GnuCash
> Windows installation. You could try to simply copy the four .scm files into
> share/guile/1.8/ and see if it works. It will only if the author didn't use
> any Guile-2-only features.
> > Regards,
> > John Ralls
> > On the security risk, it is no different than running the same process
> outside GnuCash (in a terminal for instance), or is it ?
> > The json file is there to be able to specify the options for a report in
> a better way than writing Scheme in an scm file. Currently, for a given
> python report (report_test.py), I generate the Scheme code wrapping this
> python report (report_test.scm) with:
> > - the proper Scheme code for the options defined in report_test.py
> > - the proper Scheme code to call the python process (ie "python
> > Instead of having to generate scheme code, it would be better to have a
> json file per report (report_test.json) that could be used to instantiate
> the report in GnuCash.
> > For piecash, there is no specific issue as the change in the book are
> immediately serialised to the SQL backend. However, for the xml backend
> (that piecash does not support anyway), the GnuCash file should be saved
> before. But nothing forbids someone to use the official python bindings to
> connect to the current session and do as you describe. However, how the
> python bindings know to which session to connect if there are multiple
> files opened at the same time ? and can they open a session in a separate
> process while GnuCash has a lock on the file ?
> A process running outside GnuCash isn't pushing data into a running
> instance of GnuCash, so yes, it's significantly different. The ancient
> libwebkit we use has tons of known vulnerabilities that could be exploited
Any report written in guile can be malicious as it has (i guess) full
access to the OS (syscall, file manipulation, etc) and to the gnucash
engine (I guess the report could modify the book ... but I may be wrong).
Any outside process can tinker with the gnucash books to corrupt them. So I
do not see exactly what specific security threat would be avoided by
blocking the specific case of a process running outside Gnucash pushing a
string of HTML.
> Maybe I misunderstand how the json file would work. Would it just
> initialize the options which can then be edited in the report's options
> dialog, or are the options in the json file the ones that the report gets
> and the user must edit the json file in order to change them?
> Indeed, the json is just there to 1) initalise the 'options-generator'
object (with the options information), 2) specify the process to call (via
dynamic-wind) and 3) define the report (argument for 'gnc:define-report).
It is just way more readable/editable than tinkering with scm code. But we
could choose yaml (even more readable but must find a yaml parser for
guile) or xml (less readable but xml reader available in standard guile
> Does PyCash ignore the lock table in the database, then?
piecash is well aware of the lock table in the database but you can tell
him to ignore it if you open the book in read only mode via
book = piecash.open_book(book_url, readonly=True, open_if_lock=True)
> To connect to the current session I think one would need to use the Python
> connection in src/python or the Scheme interpreter. No external process is
> going to be able to get at the running GnuCash instance's memory.
Looks complex and probably a) requires compilation and b) does not allow to
choose the python interpreter the user wants.
(as a side note, it is as an important security threat as having a guile
interpreter embedded or calling an external process ... the later being
less dangerous as he can only be dangerous through the HTML string it
> John Ralls
More information about the gnucash-devel