1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
.. _security:
Security Considerations
=======================
A full list of `Security Advisories is available on GitHub <https://github.com/sqlfluff/sqlfluff/security/advisories>`_.
Given the context of how SQLFluff is designed to be used, there are three
different tiers of access which users may have access to manipulate how the
tool functions in a secure environment.
#. *Users may have edit access to the SQL code which is being linted*. While
SQLFluff does not execute the SQL itself, in the process of the
:ref:`templating step <templater>` (in particular via jinja or dbt),
certain macros may have the ability to execute arbitrary SQL code (e.g.
the `dbt run_query macro`_). For the Jinja templater, SQLFluff uses the
`Jinja2 SandboxedEnvironment`_ to limit the execution on unsafe code. When
looking to further secure this situation, see below for ways to limit the
ability of users to import other libraries.
#. *Users may have edit access to the SQLFluff :ref:`config-files`*. In some
(perhaps, many) environments, the users who can edit SQL files may also
be able to access and edit the :ref:`config-files`. It's important to note
that because of :ref:`in_file_config`, that users who can edit SQL files
which are designed to be linted, will also have access to the vast majority
of any configuration options available in :ref:`config-files`. This means
that there is minimal additional protection from restricting access to
:ref:`config-files` for users who already have access to edit the linting
target files (as described above).
#. *Users may have access to change how SQLFluff is invoked*. SQLFluff can
be invoked either as a command line too or via the python API. Typically
the method is fixed for a given application. When thinking about how to
restrict the ability of users to call insecure code, SQLFluff aims to
provide options at the point of invocation. In particular, as described
above, the primary risk vector for SQLFluff is the macro environment
as described in :ref:`templateconfig`. To restrict users being able to
bring arbitrary python methods into sqlfluff via the ``library_path``
configuration value (see :ref:`jinja_library_templating`), we recommend
that for secure environments you override this config value either by
providing an ``override`` option to the :class:`FluffConfig` object if
using the Python API or via the ``--library-path`` CLI option:
To disable this option entirely via the CLI:
.. code-block:: bash
$ sqlfluff lint my_path --library-path none
To disable this option entirely via the python API:
.. literalinclude:: ../../../examples/04_config_overrides.py
:language: python
.. _`Jinja2 SandboxedEnvironment`: https://jinja.palletsprojects.com/en/3.0.x/sandbox/#jinja2.sandbox.SandboxedEnvironment
.. _`dbt run_query macro`: https://docs.getdbt.com/reference/dbt-jinja-functions/run_query
|
