2.3 ⁑Security
When you import data from an SQL database, you need to enter the password associated with the SQL user. This must be done each time you run datatooltk with the --sql option. While it is possible to specify the password using the --sqlpassword option, this is not advisable as it will be visible to anyone who happens to be looking over your shoulder (and will probably be remembered by the shell's history). It's also not advisable to include the password in an arara directive since it can be read by anyone with access to the document source.
However, regardless of whether or not you use the --sqlpassword option, any confidential data that was imported from the SQL database will be present in the datatool (.dbtex) file, which other users may be able to access and read. If your operating system supports different permissions for owner and others (such as Unix-based systems) you can use the --owner-only option when invoking datatooltk so that the permissions on the .dbtex are set to read and write only for the owner. For example:
On Unix-like systems this is equivalent to
$ chmod 600 people.dbtex
This means that only the owner of the file (you, if you ran the datatooltk command under your own user name) can read or write the people.dbtex file. Any other users with an account on the same machine should not be able to read or write that file. If your operating system doesn't support different owner and other permissions, the --owner-only option will have no effect.
If you are using arara the directive is:
% arara: datatooltk: { % arara: --> output: people.dbtex, % arara: --> sqluser: sampleuser, % arara: --> owneronly: true, % arara: --> sqldb: samples, % arara: --> sql: "SELECT * FROM people" }
If your SQL database contains a mixture of private and public data, but you only want to use the public data in your document, make sure you omit the private data in your SELECT statement. For example, instead of using SELECT * to fetch all columns replace the asterisk with just the columns you want to fetch. Perhaps you only want to list the countries where you have customers, then you'd just use SELECT country FROM people which would only write the country information to the .dbtex file and not the individual customer details.
Remember that TeX discards comments in the form
% ⟨comment text⟩
(unless the category code of % is changed, for example, by
the verbatim environment). Here the comment text doesn't get
hidden or embedded within the resulting PDF, but in other cases don't assume
that just because you can't see the text you've included in your
source code it won't be somehow present in the PDF file. For example
\textcolor{white}{some text}
If this text is placed on a white background, it won't be visible to the human eye, but the text will be present in the PDF file and can be read by an electronic device such as a screen reader or it can be extracted using a PDF to text tool. The censor package described in §6.4.1 Redaction: The censor Package replaces the redacted text with a black rectangle rather than simply obscuring the text by painting a black rectangle on top of it, which means that the redacted text can't be extracted from the PDF.
Unlike Word [89], LaTeX doesn't automatically embed
private information or revision logs in the document. With LaTeX you need to explicitly indicate the author or authors. This is done
through the \author command in the standard classes.
PDFLaTeX allows you to add metadata, but again this relies on you
explicitly providing the author data. (The hyperref package
provides a convenient key to do this called pdfauthor,
which can be passed as a package option or through
\hypersetup{⟨options⟩}. It's possible that other classes or
packages may use \author or provide a similar command to add
the author's name to the metadata, but it's still information
provided by you and not automatically picked up from your operating
system's environment variables or settings.)
TeX has a shell escape mechanism that allows processes to
be spawned during the document build. However, since this can be
exploited by malicious code, it's usually disabled completely or
just enabled in restricted mode, which only allows trusted
applications (such as makeindex or bibtex) to be
run. You can check the mode on your system by inspecting the log
file. For example, if the log file contains “restricted
\write18 enabled” near the start, then TeX was run in
restricted mode. The shell escape can be enabled using TeX's
-shell-escape option, for example:
or disabled using the -no-shell-escape option, for example:
or the restricted mode can be enabled using -shell-restricted, for example:
Note that -shell-escape is normally disallowed.
JavaScript code can be embedded in PDF files, which may be a security issue. The code is run by the PDF viewer when viewing the PDF file, not during the document build. If this is a concern for you, disable this feature in your PDF viewer. As with the author metadata, TeX doesn't automatically embed JavaScript code in the PDF file. You can explicitly embed JavaScript code into interactive PDF elements, but obviously don't do this if you don't understand the code you're trying to embed.
You have control over the commands you enter into your source code, but what about the document class or packages that you load? If you have the shell escape disabled or restricted, then this automatically prevents any class or package from running dangerous applications. Some classes or packages may embed JavaScript code if their purpose is to create an interactive PDF document. If this concerns you, disable JavaScript in your PDF viewer, as mentioned above. Remember also that class and package files can be viewed in any text editor, so it's possible to inspect the code. While this may not appeal to you, if it's a well-used class or package that's on both MiKTeX and TeX Live, then the chances are that someone else already has.
What about applications such as arara and latexmk? You can add code to latexmk through the .latexmkrc file, but if you're writing the code, you should know what that code does. It's possible to embed Java code within the conditional part of arara directives, but again if you are writing the code it's up to you to ensure you don't write anything dangerous. If someone else has supplied a LaTeX document that contains arara directives, you can search for them in the document source file before running arara on it. However arara will only execute a directive that has a corresponding .yaml file in its rules directory, and you can also use --dry-run to see what commands would be executed.
Remember that if the application is available on TeX Live, then it has to have the source available. In fact, since latexmk is a Perl script, you can open it in a text editor. The arara directives are all defined in .yaml files, which again can be viewed in a text editor. An active open source community with a central file repository is far more likely to detect and flag malicious code than any users of proprietary systems.
But what if someone accesses your computer and modifies the .latexmkrc or .yaml files? In that case, you have far more to worry about than the integrity of your TeX distribution.
Other security issues you might want to consider are discussed in §6.4 Confidentiality and §13 Collaborating on Documents.
This book is also available as A4 PDF or 12.8cm x 9.6cm PDF or paperback (ISBN 978-1-909440-07-4).