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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
.Dd January 24, 2024
.Dt SQLITE3_SET_AUTHORIZER 3
.Os
.Sh NAME
.Nm sqlite3_set_authorizer
.Nd compile-Time authorization callbacks
.Sh SYNOPSIS
.In sqlite3.h
.Ft int
.Fo sqlite3_set_authorizer
.Fa "sqlite3*"
.Fa "int (*xAuth)(void*,int,const char*,const char*,const char*,const char*)"
.Fa "void *pUserData"
.Fc
.Sh DESCRIPTION
This routine registers an authorizer callback with a particular database connection,
supplied in the first argument.
The authorizer callback is invoked as SQL statements are being compiled
by
.Fn sqlite3_prepare
or its variants
.Fn sqlite3_prepare_v2 ,
.Fn sqlite3_prepare_v3 ,
.Fn sqlite3_prepare16 ,
.Fn sqlite3_prepare16_v2 ,
and
.Fn sqlite3_prepare16_v3 .
At various points during the compilation process, as logic is being
created to perform various actions, the authorizer callback is invoked
to see if those actions are allowed.
The authorizer callback should return SQLITE_OK to allow the
action, SQLITE_IGNORE to disallow the specific action
but allow the SQL statement to continue to be compiled, or SQLITE_DENY
to cause the entire SQL statement to be rejected with an error.
If the authorizer callback returns any value other than SQLITE_IGNORE,
SQLITE_OK, or SQLITE_DENY then the
.Fn sqlite3_prepare_v2
or equivalent call that triggered the authorizer will fail with an
error message.
.Pp
When the callback returns SQLITE_OK, that means the operation
requested is ok.
When the callback returns SQLITE_DENY, the
.Fn sqlite3_prepare_v2
or equivalent call that triggered the authorizer will fail with an
error message explaining that access is denied.
.Pp
The first parameter to the authorizer callback is a copy of the third
parameter to the sqlite3_set_authorizer() interface.
The second parameter to the callback is an integer action code
that specifies the particular action to be authorized.
The third through sixth parameters to the callback are either NULL
pointers or zero-terminated strings that contain additional details
about the action to be authorized.
Applications must always be prepared to encounter a NULL pointer in
any of the third through the sixth parameters of the authorization
callback.
.Pp
If the action code is SQLITE_READ and the callback returns
SQLITE_IGNORE then the prepared statement
statement is constructed to substitute a NULL value in place of the
table column that would have been read if SQLITE_OK had been
returned.
The SQLITE_IGNORE return can be used to deny an untrusted
user access to individual columns of a table.
When a table is referenced by a SELECT but no column values are
extracted from that table (for example in a query like "SELECT count(*)
FROM tab") then the SQLITE_READ authorizer callback is invoked
once for that table with a column name that is an empty string.
If the action code is SQLITE_DELETE and the callback returns
SQLITE_IGNORE then the DELETE operation proceeds
but the truncate optimization is disabled and
all rows are deleted individually.
.Pp
An authorizer is used when preparing SQL statements from an
untrusted source, to ensure that the SQL statements do not try to access
data they are not allowed to see, or that they do not try to execute
malicious statements that damage the database.
For example, an application may allow a user to enter arbitrary SQL
queries for evaluation by a database.
But the application does not want the user to be able to make arbitrary
changes to the database.
An authorizer could then be put in place while the user-entered SQL
is being prepared that disallows everything except SELECT
statements.
.Pp
Applications that need to process SQL from untrusted sources might
also consider lowering resource limits using
.Fn sqlite3_limit
and limiting database size using the max_page_count PRAGMA
in addition to using an authorizer.
.Pp
Only a single authorizer can be in place on a database connection at
a time.
Each call to sqlite3_set_authorizer overrides the previous call.
Disable the authorizer by installing a NULL callback.
The authorizer is disabled by default.
.Pp
The authorizer callback must not do anything that will modify the database
connection that invoked the authorizer callback.
Note that
.Fn sqlite3_prepare_v2
and
.Fn sqlite3_step
both modify their database connections for the meaning of "modify"
in this paragraph.
.Pp
When
.Fn sqlite3_prepare_v2
is used to prepare a statement, the statement might be re-prepared
during
.Fn sqlite3_step
due to a schema change.
Hence, the application should ensure that the correct authorizer callback
remains in place during the
.Fn sqlite3_step .
Note that the authorizer callback is invoked only during
.Fn sqlite3_prepare
or its variants.
Authorization is not performed during statement evaluation in
.Fn sqlite3_step ,
unless as stated in the previous paragraph, sqlite3_step() invokes
sqlite3_prepare_v2() to reprepare a statement after a schema change.
.Sh IMPLEMENTATION NOTES
These declarations were extracted from the
interface documentation at line 3124.
.Bd -literal
SQLITE_API int sqlite3_set_authorizer(
sqlite3*,
int (*xAuth)(void*,int,const char*,const char*,const char*,const char*),
void *pUserData
);
.Ed
.Sh SEE ALSO
.Xr sqlite3 3 ,
.Xr sqlite3_limit 3 ,
.Xr sqlite3_prepare 3 ,
.Xr sqlite3_step 3 ,
.Xr sqlite3_stmt 3 ,
.Xr SQLITE_CREATE_INDEX 3 ,
.Xr SQLITE_DENY 3 ,
.Xr SQLITE_OK 3
|
