How safe is GnuCash?

Thu Jan 12 13:18:34 EST 2017

Jean-David is correct.  Apple’s OS X is  BSD Unix derivative.  While its architecture is somewhat different than linux, and its philosophy as a proprietary OS is very different, for the purposes of this discussion they are the same enough.  As is FreeBSD which is for all practical purposes the BSD distribution updated and enhanced. 

Accounting systems, whether they be commercial or not, irrespective of the OS that runs them can be altered.  Either in the data or in the internal workings.  And it does happen.  There is no completely safe system and no system that cannot eventually breached.  The only things we can do is make it difficult and make the breaches detectable.  But, if one had a mind to retrospectively change a journal entry, it can be done on any accounting system, including the widely used commercial varieties.  In that respect, GnuCash does not appear to be any different than the others.  It is safe in that it appears to work the way a double entry book-keeping system should work.  It is reliable in that it doesn’t appear to lose data or transactions, and with appropriate audit and systems controls and policies, can be as safe as any other system.

If for example you were worried about someone in the middle of the night altering journal entries, it can be done.  There are a number of means to prevent this or detect it.  To describe this for you I’ll use a unix like OS (FreeBSD or Apple OS X which I’m very familiar, windows, not so much).
One possible scheme is this:

1.  Gnucash is set up on your system.  Its permissions are set to only allow a few select or only a single user  access.
2.  Presumably that user is allowed access via a password or shared key system, and the password (if used) is complex.  This is your first line of safety.
3.  Gnucash is set up and used, as is typical for your application.
4.  At the end of each session, after gnucash is closed, all of its files are copied to off line media, these files are write protected, and copied (i.e. a memory stick)and  removed from the system and stored in a locked place.
5.  Prior to opening gnu cash, you remove the off line copy from its safe, and make it available to your computer running gnucash. 
6.  Using an OS utility, (diff in linux/FreeBSD/OSX), you can see if any changes were made.  If not, you are good to go to work.    With a little creativity, fairly easy methods can be used to check at the byte level using a combination of hexdump and diff or a variety of file comparison utilities.  I’m not sure what microsoft uses in this arena, but in the past it was pretty primitive.
7.  If on the other hand, someone did make an unauthorized change, this can then be investigated.

By adopting a policy scheme such as this, you can provide at least reasonable assurances to the auditors that no unauthorized changes were made and there is a verifiable audit trail.  A paper copy of the diff output stored in a secure place after each day can be used.  

This scheme will not help if there are intra-day alterations made by authorized users.  It only ensures day to day integrity and there were no surreptitious alterations of the books.  You can make this safer by requiring two people to be present at each step.

Changes made by an authorized user(s) are another matter.

What I think you are asking is to not permit alteration of entries, once they are made and to provide a means of identifying who made the alteration.  

I’m not sure that gnucash does this.  If gnucash were set up this way, by making a journal entry unalterable, and by providing a separate audit transaction file where each period’s entries were recorded, this could be accomplished.  

There was some discussion about this some time ago, and it may be possible to lock entry changes, after a period of time, but I’m not sure since I’ve never implemented this feature and don’t need to for my purposes.  If it is possible and by doing a combination of the above, you can be reasonably sure your ledgers are not altered.  If gnucash does permit this, then the only way to change a locked journal transaction within gnucash would be to create offsetting debit/credit transactions to fix the error, which would show up as  separate journal entries.  I don’t think that gnucash has any provision to track transactions by user, which means you cannot tell which user entered a transaction unless you set your system up as a single user access only. 

> On Jan 12, 2017, at 6:12 AM, Jean-David Beyer <jeandavid8 at verizon.net> wrote:
> 
> On 01/11/2017 02:10 PM, 70147persson at telia.com wrote:
>> How safe is GnuCash? No, I am not talking about lack of bugs etc, but
>> from an auditor's point of view. How to secure that no one is
>> manipulating the figures in the book? The best way of book keeping is
>> an, in advance paginated, paper book, in which you write your notes with
>> non erasable ink. Then, if I make a mistake, I have to make a change by
>> drawing a straight line (in ink) over the wrong figures and write the
>> correct ones next to the original and sign it with my signature. That
>> way the auditor can see all changes and can verify it to the written
>> documents/verifications.
>> 
> I am not an expert on GnuCash, thouogh I have used it for many years.
> 
> But let us imagine that the GnuCash program is perfect in every respect
> according to whatever specification you try to make on it. You are still
> not safe because any one (e.g., the system administrator) can modify a
> GnuCash file using a program other than GnuCash.
> 
> In Linux, for example, there are programs that allow anyone with the
> proper permissions to alter any kind of file. Sed is one of them; ospam
> might be more convenient. And there is nothing Gnucash can do to prevent
> you from using it. Now if the GnuCash data file is owned by a specific
> user (and this is usually the case), and that user made it and its
> containing directry unwritable (and perhaps unreadable as well by
> members of his group or any others), it would be more difficult for a
> random user to fiddle with the file. But the system administrator (root)
> could do it with ease. And if that Linux system were running SELinux
> (Security Enhanced Linux), it would be more difficult still. But still
> not impossible.
> 
> I do not know enough about Windows or Apple software to comment on
> security of those systems, but I doubt your problems would be solved by
> using them.
> 
> -- 
>  .~.  Jean-David Beyer          Registered Linux User 85642.
>  /V\  PGP-Key:166D840A 0C610C8B Registered Machine  1935521.
> /( )\ Shrewsbury, New Jersey    http://linuxcounter.net
> ^^-^^ 06:55:01 up 1 day, 15:40, 2 users, load average: 4.29, 4.27, 4.19
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.