How to allow macros in LibreOffice/share/basic for AutoOpen

If I setup macro security to very high I am able to put the read only template folder in the list of secure locations and running a macro on DocumentCreate works. Unfortunately the new document looses its connection with the template, so it is not possible to have a read only secure folder for macros this way after the initial creation of the document.

If I instead put all macros in a library in the installation path (/usr/lib/libreoffice/share/basic or C:\Program Files\LibreOffice\share\basic), which is again readonly for regular users, all of these macros are running fine, if (!) I start them by hand. If I attach one of these macros to a DocumentOpen event it will trigger the yellow bar stating running macros is not allowed. I find this quite inconsistent and wrong, as systemwide macros in the system folder should in my opinion be runnable no matter what.

Is there any way to get to run a macro securely, that is from a read only location, automatically on DocumentOpen?

The trusted paths do not refer to the code. They refer to the location of documents allowed to call macro code.
Simple rule: Include your documents directory or some subdirectory therein, but never allow the downloads directory.

There is code in those locations that may be used for unexpected purposes, e.g., to read files. The location of the code (that it is in a “locked” place) is not a guarantee that executing it from untrusted file is safe.

I didn’t quite understand the question.
If a user adds a resource available to other users to the list of trusted locations, files in that folder containing macros will open without further prompting. Macros bound to the file open event will also run without further prompting.

This would be highly insecure indeed, anybody might move files from the download folder into one of those trusted paths. As stated in the BSI document security in LibreOffice, trusted paths must not be writable by users.

Well, first they have to move downloaded files deliberately into their own document space where they should be able to do whatever they want. Read-only documents calling macros make no sense, unless the macros manipulate documents other than the calling one which is a rare corner case.

In my opinion, this is a common practice for companies: sample documents (and/or templates) in a shared folder. Authors have full access, while consumers have read-only access.
The document may contain macros, menus, …

1 Like

As these macros are executed in any insecure document I do not see your point. Give it a try yourself, put a document in an insecure location and try to run one of the macros included with LibreOffice, they are all working. You will not be able to attach them to an DocumentOpen event, which is my point.

The point is: when you execute macros, it is your decision to run that code. But when you open a document, and it wants to run some code without telling you, it’s completely different story - the same code (maybe even located in safe place) could be used for very different things, including sending some data to unknown person. In this case, what is important is not where the code is located, but if the opened document is trusted to not abuse it.

Note also, that extending your logic, all runnable code is safe: eventually, it uses the code in LibreOffice binaries (functions created in C++), all of which is (usually, and likely in your case) in not-user-writable place.

As I am strictly following the recommendations of the Federal Office for Information Security (BSI) I may have runnable basic code only in locations not writable by regular users but instead only assigned template designers.

As regular users have no write access to the installation path putting our companies macros there will suffice, any macro in that place is allowed to run by default. The remaining problem was the customization of the “Open Document” event triggering the yellow “Macros disabled” notification. The first part of the solution to my problem was hiding in plain daylight, this customization may be saved instead of the document in the LibreOffice configuration. A macro attached to “Open Document” will run with no further configuration while having “Macro Security” at very high, if it is saved in this way.

The second part of the solution was finding a way to run the document specific AutoOpen macro. In our setup there are a set of macros for every template, each bundled in a module of the same name. I only needed a way to circumvent errors if some template would not need a “Document Open” event and thus had no AutoOpen in its module. This is my code for this requirement:

Sub AutoOpen(Ereignis)
   On Error Goto X

   Dim script As Object
   script=ThisComponent.ScriptProvider.getScript("vnd.sun.star.script:Eibo." & Ereignis.Source.DocumentProperties.TemplateName & ".AutoOpen?language=Basic&location=application")

   script.invoke( array(Ereignis), array(), array())
 X: 
End Sub


With this setup it is possible to get a decent and secure operating environment with strict restrictions and full automization.

2 Likes