Documentation Source Text

Check-in [518f7b3bdd]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Add SQLITE_DIRECTONLY to the change log and documentation. Fix a typo in changes to the index_info pragma.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 518f7b3bdd4b95e5d282baef2657996c599b22f9cad9d2057de06e9595844dd0
User & Date: drh 2019-09-16 14:49:18
Context
2019-09-26
15:24
Adjustments to the document indexes. check-in: ede6ba1df3 user: drh tags: trunk
2019-09-16
14:49
Add SQLITE_DIRECTONLY to the change log and documentation. Fix a typo in changes to the index_info pragma. check-in: 518f7b3bdd user: drh tags: trunk
14:09
Remove documentation fixes from the release branch. check-in: b10a80aacd user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/changes.in.

34
35
36
37
38
39
40



41
42
43
44
45
46
47
     it recovers more content from corrupt database files.
<li> Enhance the [RBU] extension to support [indexes on expressions].
<li> Change the schema parser so that it will error out if any of
     the type, name, and tbl_name columns of the [sqlite_master table]
     have been corrupted and the database connection is not in
     [writable_schema] mode.
<li> Add the [SQLITE_DBCONFIG_ENABLE_VIEW] option for [sqlite3_db_config()].



<li> The legacy [SQLITE_ENABLE_STAT3] compile-time option is now a no-op.
}

chng {2019-07-10 (3.29.0)} {
<li> Added the [SQLITE_DBCONFIG_DQS_DML] and [SQLITE_DBCONFIG_DQS_DDL]
     actions to [sqlite3_db_config()] for activating and deactivating
     the [double-quoted string literal] misfeature.  Both default to "on"







>
>
>







34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
     it recovers more content from corrupt database files.
<li> Enhance the [RBU] extension to support [indexes on expressions].
<li> Change the schema parser so that it will error out if any of
     the type, name, and tbl_name columns of the [sqlite_master table]
     have been corrupted and the database connection is not in
     [writable_schema] mode.
<li> Add the [SQLITE_DBCONFIG_ENABLE_VIEW] option for [sqlite3_db_config()].
<li> Added the [SQLITE_DIRECTONLY] flag for
     [application-defined SQL functions] to prevent those functions from
     being used inside triggers and views.
<li> The legacy [SQLITE_ENABLE_STAT3] compile-time option is now a no-op.
}

chng {2019-07-10 (3.29.0)} {
<li> Added the [SQLITE_DBCONFIG_DQS_DML] and [SQLITE_DBCONFIG_DQS_DDL]
     actions to [sqlite3_db_config()] for activating and deactivating
     the [double-quoted string literal] misfeature.  Both default to "on"

Changes to pages/pragma.in.

1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
....
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
    <ol>
    <li>^(The rank of the column within the index.  (0 means left-most.))^
    <li>^The rank of the column within the table being indexed.
    <li>^The name of the column being indexed.
    </ol>

    <p>If there is no index named <i>index-name</i> but there is a
    [WITHOUT ROWID] table name <i>index_name</i>, then (as of
    SQLite [version 3.30.0] on [dateof:3.30.0]) this pragma returns the
    PRIMARY KEY columns of the WITHOUT ROWID table as they are used
    in the records of the underlying b-tree, which is to say with
    duplicate columns removed.
}

Pragma index_xinfo {
................................................................................
    <li>^The name for the [collating sequence]
         used to compare values in the index-column.
    <li>^1 if the index-column is a key column and 0 if the index-column
         is an auxiliary column.
    </ol>

    <p>If there is no index named <i>index-name</i> but there is a
    [WITHOUT ROWID] table name <i>index_name</i>, then (as of
    SQLite [version 3.30.0] on [dateof:3.30.0]) this pragma returns the
    columns of the WITHOUT ROWID table as they are used
    in the records of the underlying b-tree, which is to say with
    de-duplicated PRIMARY KEY columns first followed by data columns.
}

Pragma index_list {







|







 







|







1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
....
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
    <ol>
    <li>^(The rank of the column within the index.  (0 means left-most.))^
    <li>^The rank of the column within the table being indexed.
    <li>^The name of the column being indexed.
    </ol>

    <p>If there is no index named <i>index-name</i> but there is a
    [WITHOUT ROWID] table with that name, then (as of
    SQLite [version 3.30.0] on [dateof:3.30.0]) this pragma returns the
    PRIMARY KEY columns of the WITHOUT ROWID table as they are used
    in the records of the underlying b-tree, which is to say with
    duplicate columns removed.
}

Pragma index_xinfo {
................................................................................
    <li>^The name for the [collating sequence]
         used to compare values in the index-column.
    <li>^1 if the index-column is a key column and 0 if the index-column
         is an auxiliary column.
    </ol>

    <p>If there is no index named <i>index-name</i> but there is a
    [WITHOUT ROWID] table with that name, then (as of
    SQLite [version 3.30.0] on [dateof:3.30.0]) this pragma returns the
    columns of the WITHOUT ROWID table as they are used
    in the records of the underlying b-tree, which is to say with
    de-duplicated PRIMARY KEY columns first followed by data columns.
}

Pragma index_list {

Changes to pages/security.in.

132
133
134
135
136
137
138












139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
If the application does use triggers or views, then use queries to
scan the [sqlite_master] table to verify that the triggers and views
found there are expected, that there are no surplus triggers or views,
existing triggers and views have not been tampered with,
and that no existing ordinary tables have been replaced by
malicious views.
</p>












</ol>
</ol>


<p>Even if the application does not deliberately accept database files
from untrusted sources, beware of attacks in which a local database file
is surreptitiously altered to contain harmful content.

<h1>Summary</h1>

<p>
The precautions above are not required in order to use SQLite safely
with potentially hostile inputs.
However, they do provide an extra layer of defense against zero-day
exploits and are encouraged for applications that pass data from
untrusted sources into SQLite.







>
>
>
>
>
>
>
>
>
>
>
>


<













132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152

153
154
155
156
157
158
159
160
161
162
163
164
165
If the application does use triggers or views, then use queries to
scan the [sqlite_master] table to verify that the triggers and views
found there are expected, that there are no surplus triggers or views,
existing triggers and views have not been tampered with,
and that no existing ordinary tables have been replaced by
malicious views.
</p>
<li><p>
If the application uses [application-defined SQL functions] that have
side effects, then it is recommended to set the [SQLITE_DIRECTONLY] flag
on those SQL functions to prevent them from being used inside triggers
and views.  To illustrate the importants of this flag, consider an
application that implements an SQL function "send_money(...)".  Without
the SQLITE_DIRECTONLY flag, an attacker might be able to add a trigger
or view that uses that custom function, then trick a
high-privilege application to run an otherwise harmless query that invokes
that malicious trigger or view.  The SQLITE_DIRECTONLY flag prevents the
attack by requiring the "send_money()" function to be invoked directly
by the application, rather than indirectly through a trigger or view.
</ol>
</ol>


<p>Even if the application does not deliberately accept database files
from untrusted sources, beware of attacks in which a local database file
is surreptitiously altered to contain harmful content.

<h1>Summary</h1>

<p>
The precautions above are not required in order to use SQLite safely
with potentially hostile inputs.
However, they do provide an extra layer of defense against zero-day
exploits and are encouraged for applications that pass data from
untrusted sources into SQLite.